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ABSTRACT 


Strategic  planning  is  receiving  increased  emphasis  in 
both  public  and  private  sector  organizations.  This 
increased  emphasis  has  recently  been  evident  in  the  Naval 
Supply  Systems  Command  (NAVSUPj  which  issued  its  formal 
Strategy  :  Plan  in  June  1985. 

After  issuance  of  such  a  plan,  organizational  components 
should  realign  their  programs  and  projects  to  become  in 
consonance  with  the  corporate  plan  of  action.  This  thesis 
analyzes  the  existing  and  planned  Stock  Point  Logistics 
Integrated  Communications  (SPLICE)  Project  initiatives  in 
light  of  the  NAVSUP  Strategic  Plan.  The  results  of  these 
analyzes  are  recommend  at i ons  which  will  bring  the  SPLICE 
Project  application,  external  system  interface,  and  system 
migration  plans  into  closer  harmony  with  the  NAVSUP 
Strategic  Plan. 
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I.  INTRODUCTION 


A.  THE  PURPOSE 

Tne  purpose  of  this  thesis  is  to  assist  the  Nazal  Supply 
Systems  Command  (NAVSUP)  Stock  Point  Logistics  Integrated 
Communications  Environment  (SPLICE)  project  office,  SUP 
0472,  in  accomplishing  the  task  of  strategic  and,  to  a 
limited  extent,  tactical  project  planning.  As  a  result  of 
this  effort,  a  long  range  SPLICE  project  planning  guide  will 
emerge. 

B.  THE  PLANNING  PROBLEM 

Since  this  thesis  will  address  project  planning,  tne 
immediate  problem  becomes:  upon  what  should  SPLICE  project 
planning  be  based  within  NAVSUP?  Once  this  question  is 
answered,  the  follow-on  problem  of  what  changes  must  be  made 
to  the  existing  SPLICE  project  plans  will  be  addressed,  in 
light  of  the  answer. 

C.  METHODOLOGY 

A  key  element  that  appears  to  differentiate  well  managed 
o r g a n i z a t i o n s  from  average  or  mediocre  o rg a n  i  z a t  i  o n s  is  the 
degree,  levels,  and  cohesiveness  of  planning  used  by 
management.  Thompson  and  Strickland  [Ref.  1]  support  this 
position.  Their  research  leads  them  to  claim  that  managers 
in  more  successful  o r g a n  i  z a t  i  o n s  make  time  to  formulate  a 


systematic  blueprint  of  management's  answers  to  three 
critical  questions: 

1.  What  does  the  organization  do  and  for  whom? 

2.  What  objectives  does  the  organization  want  to 
achieve,  over  what  period  of  time,  and  how  are  these 
objectives  measured? 

3.  How  must  the  organization  be  managed  or  changed  to 
achieve  the  objectives  and  measure  performance? 

Tne  document  which  an  organization  produces  that  contains 

the  answers  to  these  questions  is  its  strategic  plan. 

At  the  highest  levels  of  management,  a  strategic  plan 
may  be  referred  to  as  a  corporate  plan.  To  have  any  degree 
of  impact  on  an  organization,  a  strategic  plan  must  be 
embraced  by  all  levels  of  management  and  translated  into 
associated  lower  level  plans  of  action  or  strategies  with 
stated  measurable  objectives.  At  middle  management  levels, 
the  implementation  strategies  and  objectives  to  achieve  the 
corporate  goals  are  called  business  plans  or  functional  area 
plans.  In  terms  of  automated  data  processing  (ADP) 
systems,  the  applicable  functional  area  plan  is  often 
referred  to  as  the  Management  Information  Systems  Plan  and 
its  correspond i ng  architecture  [Ref.  2].  At  the  lowest 
levels  of  management,  operational,  tactical,  or  project 
plans  provide  "the  nuts  and  bolts"  of  how  the  business  or 
functional  area  plans  will  oe  carried  out.  Success  or 
failure  of  the  corporate  plan  depends  heavily  on  how  well 
the  lower  level  plans  fit  or  are  made  to  fit  the  corporate 
strategy,  how  performance  is  measured,  and  how  corrective 


action  is  applied  to  lower  level  plans  for  deviations  from 
the  corporate  plan. 

The  Tnompson  ana  Strickland  model  of  basing  operational, 
tactical,  or  project  plans  on  corporate  and  functional  area 
plans  will  be  tne  methodology  used  within  this  thesis  for 
proposing  modifications  to  SPLICE  project  plans. 

D.  THE  NAVSUP  STRATEGIC  PLAN 

The  trend  found  in  the  more  successful  organizations  to 
perform  formal  corporate  planning  has  not  gone  unnoticed  in 
the  public  sector.  Of  particular  importance  to  this  thesis 
was  the  decision  by  NAVSUP  in  1985  to  produce  a  formal 
corporate  plan,  which  was  called  the  NAVSUP  Strategic  Plan 
[Ref.  3 ] . 

Tne  NAVSUP  Strategic  Plan  is  the  result  of  over  a  years 
worth  of  effort  by  headquarters  top  management  personnel  in 
mapping  where  the  "corporation"  is  and  where  it  should  be 
going.  It  essentially  replaces  previous  NAVSUP  strategy  ana 
planning  tools,  such  as  the  “Key  Indictor"  program  and  the 
"Top  Concerns"  lists.  An  indication  of  the  seriousness  of 
this  planning  effort  comes  from  the  fact  that  during  a  tnree 
month  period  within  this  year,  virtually  all  Division 
Directors  and/or'  Deputies  at  the  headquarters  were 
sequestered  to  an  off  site  location  (from  NAVSUP)  to  permit 
undivided  attention  to  the  development  of  tnis  plan. 
Subsequent  actions  taken  in  support  of  tnis  plan  included 
numerous  area  specific  steering  committee  meetings  and  a 


r eo r g an i z a t  i  o n  of  some  d i r ec to r a t e s  at  NAVSUP  itself  in 
order  to  better  implement  the  plan. 

The  NAVSUP  Strategic  Plan  restructured  the  three  basic 
questions  posed  by  Thompson  and  Strickland  into  the 
following  four  questions: 

1.  What  is  our  job? 

2 .  Who  are  we? 

3.  Where  are  we  going? 

4.  How  do  we  get  there? 

The  plan  answers  the  first  question  in  terms  of 
reiterating  the  NAVSUP  mission,  including  its  scope  and 
responsibilities.  The  second  question  is  answered  in  terms 
of  defining  the  internal  and  external  environment  NAVSUP 
faces.  The  environment  is  described  in  terms  of  a  detailed 
corporate  profile  and  a  listing  of  laws,  regulations  and 
policy  directions  with  which  it  must  coexist.  The  third 
question  was  answered  by  defining  nine  critical  success 
factors  with  related  goals.  In  the  context  of  this  plan, 
goals  appear  as  long  term  results  that  NAVSUP  wishes  to 
achieve.  The  final  question  was  answered  in  terms  of 
stating  78  opportunities,  65  assumptions,  38  strategies,  and 
125  objectives.  Opportunities  appear  as  situations  which 
may  be  developed  or  capitalized  upon  for  the  advancement  of 
the  organization.  Assumptions  are  statements  about  the 
anticipated  future  position  of  the  organization.  Strategies 
appear  as  means  to  accomplish  goals  by  providing  corporate 


direction  and  intent.  Objectives  appear  as  immediate,  short 
run  actions  which  implement  strategies  and  which  should  be 
supported  by  tactical  initiatives.  ODjectives  are  measured 
through  estimated  completion  dates  only. 

E.  THE  NAVSUP  STRATEGIC  INFORMATION  SYSTEM  PLAN 

The  task  of  developing  an  Information  Systems  Plan  which 
supports  the  Strategic  Plan  fell  under  the  purview  of  the 
NAVSUP  Deputy  Commander  for  Inventory  and  Information 
Systems  Development  (SUP  04).  SUP  04  directed  the  creation 
of  an  Information  Systems  Steering  Committee  and  Planning 
Team  with  representatives  from  each  SUP  04  division  to 
develop  the  NAVSUP  Strategic  Information  Systems  Plan. 

Using  the  format  of  the  NAVSUP  Strategic  Plan,  the  same  four 
basic  questions  were  answered,  but  the  answers  were  tailored 
to  the  specific  mission  area  of  SUP  04.  The  definitions  of 
goals,  opportunities,  assumptions,  strategies,  and 
objectives  appear  consistent  with  those  used  in  the  NAVSUP 
Strategic  Plan.  The  result  of  this  effort  was  the  approved 
NAVSUP  Strategic  Information  Plan  of  12  June  1985  [Ref.  4]. 

Using  the  Thompson  and  Strickland  model,  the  SPLICE 
project,  which  falls  under  SUP  04,  should  base  its  project 
plans  upon  the  new  NAVSUP  Strategic  Information  System  Plan, 
which  itself  is  based  upon  the  NAVSUP  Strategic  Plan.  It  is 
appropriate,  therefore,  to  examine  the  NAVSUP  Strategic 
Information  Systems  Plan  prior  to  discussing  specific  SPLICE 
project  plans  or  changes  to  them. 


The  seven  goals  listed  in  the  NAVSUP  Strategic 


Information  System  Plan  are  directly  related  to  eight  of  the 
nine  critical  success  factors  and  associated  goals  listed  in 
the  NAVSUP  Strategic  Plan.  These  goals  are: 

1.  Assure  that  the  Material  Requirements  Determination 
Program  fully  supports  fleet  and  weapons  system 
logistics  support  requ i rements  . 

2.  Establish  and  administer  an  effective  NAVSUP 
Information  Resources  Management  Program  including 
data  administration,  so  that  information  is  managed  as 
a  resource. 

3.  Assure  that  on-going  and  future  information  system 
initiatives  provide  security,  data  accuracy,  maximum 
integration,  and  timely  return  on  investment. 

4.  Assure  that  NAVSUP  information  system  mod er n  i  za t  i  on 
efforts  result  in  improved  user  effectiveness, 
increased  productivity,  and  better  use  of  Navy 
resources. 

5.  Obtain  and  retain  qualified  personnel  including 
functional  specialists  who  can  articulate  user 
requirements  in  the  system  design  process. 

6.  Ensure  SUP  04  develops  and  maintains  comprehensive 
strategic  and  tactical  plans,  performs  effective 
budgeting,  and  efficiently  manages  its  corporate 
assets  consistent  with  the  overall  NAVSUP  mission  and 
goal s . 

7.  Assure  that  NAVSUP  effectively  exploits  new  and 
emerging  information  system  technology. 

Of  these  seven  goals,  all  but  number  five  are  seen  as 

directly  impacted  by  the  SPLICE  project.  SPLICE  can  also 

support  number  five  indirectly  through  the  applications 

which  utilize  it. 

The  heart  of  NAVSUP  Strategic  Information  System  Plan 
lies  in  the  Opportun i t ies ,  Assumptions,  Strategies  and 
Objectives  portions  of  the  plan.  These  documents  are 


reproduced,  in  part,  as  appendices  A  througn  D • 1  Since  the 
information  contained  in  these  four  documents  is  so  critical 
to  lower  level  planning  efforts,  i n t e r pr e t a t i o n  of  some 
statements  contained  therein  is  necessary. 

First,  the  identified  opportunity  area  will  De 
addressed.  Sixty-three  opportunities  were  developed  by  the 
Steering  Committee.  These  opportunities  "identified 
programmatic  and  technical  options  available  to  SUP  04  to 
improve  operations  and  information  systems  effectiveness" 
[Ref.  5 ] .  Of  these  63  opportunities,  28  are  seen  as 
applicable  to  SPLICE  and  assumed  operative.  These  28 
opportunities  are  identified  in  Appendix  A  by  an  asterisk 
(*)  positioned  next  to  the  opportunity  number.  Three  of 
these  28  opportunities  require  further  qualification  in 
terms  of  this  document. 

Opportunity  number  18  refers  to  the  i  nc o r po r a t i o n  of 
common  data  elements  in  an  "integrated  data  base 
environment"  which  is  to  serve  Inventory  Control  Points, 
Stock  Points,  Headquarters  System  Commands,  and  other  ashore 

^Although  the  NAVSUP  Strategic  Information  Systems  Plan 
critical  success  factors  and  associated  goals  are 
specifically  cross-referenced  to  the  NAVSUP  Strategic  Plan, 
the  follow-on  opportunities,  assumptions,  strategies,  ana 
objectives  are  not  in  all  cases  (in  the  version  held  by  the 
authors).  The  authors  assume  that  all  the  NAVSUP  Strategic 
Information  Systems  Plan  opportunities,  assumptions, 
strategies,  and  objectives  completely  and  correctly 
correspond  to  those  of  the  senior  level  plan,  particularly 
those  which  indicate  SUP  04  lead  or  assist  responsibility. 


and  afloat  units.  The  purpose  of  this  is  to  reduce  data 
redundancy  and  promote  sharing,  accessibility,  and  accuracy. 

This  opportunity  implies  that  when  geographical  1 y 
distinct  system  users  or  applications  require  use  of  common 
aata,  rather  than  store  it  locally  (  i  .  e . ,  redundantly)  tne 
user  or  application  should  be  able  to  access  a  centralized 
data  storage  facility  to  obtain  that  data,  in  real-time. 

Data  so  provided  would  be  used  in  subsequent  local 
processi ng . 

Martin  [Ref.  6]  directly  addresses  this  situation  and 
states  that  commercially  available  data  base  management 
software  is  designed  to  work  in  a  single  computer 
environment  or  in  a  basically  homogeneous  computer  complex. 
Few  cooperative  or  even  multiple  vendor  hardware  (i.e., 
non-IBM  compatible)  data  base  management  systems  exist,  the 
notable  exception  being  ORACLE.  No  mul t i -vendor  , 
integrated,  distributed,  and  real-time  database  management 
system  currently  exists  which  supports  all  logistics  system 
hardware  suites.  This  fact  will  severely  curtail  efforts  to 
reduce  data  redundancy. 

With  the  wide  divergence  among  hardware  and  software 
used  by  the  logistics  user  community,  their  geographical 
dispersion,  and  their  local  operational  system  response  time 
requ i r ements ,  the  creation  of  an  "integrated  data  base 
environment"  to  achieve  reduced  data  redundancy  throughout 
the  logistics  system  as  implied  in  opportunity  number  18 


appears  overly  ambitious.  With  the  hardware  and  software 
suits  available,  it  may  be  possible  to: 

1.  define  and  implement  common  data  element  definitions 
within  a  multitude  of  data  dictionary/data  directory 
systems; 

2.  ana  provide  i nteroperab  i  1  i  ty  among  the  various  users 
for  access  to  individual  data  bases. 

However,  the  use  of  common  logistics  data  elements  in  an 

integrated,  cooperative,  and  distributed  data  base 

environment  across  all  logistics  systems  users  without 

redundancy  and  meeting  short  response  times  does  not  appear 

technically  or  operationally  feasible  for  the  foreseeable 

future . 

Tnis  document  assumes  that  the  opportunity  for  reduction 
in  data  redundancy  is  limited  to  individual  NAVSUP 
collocated  data  bases,  with  incompatible  or  non-contiguous 
systems  using  redundant  data,  where  necessary  to  meet  real¬ 
time  response  requ i rements  . 

Opportunity  number  23  describes  the  promotion  of 
competition  in  future  information  system  resource 
acquisitions  through  the  use  of  portable  and  machine 
independent  application  programs.  This  opportunity  must  be 
interpreted  from  two  aspects. 

First,  since  most  data  base  management  systems, 
transaction  processing  monitors,  and  fourth  generation 
languages  are  not  portable,  applications  which  use  these 
facilities  will  be  machine,  or  compatible  hardware 
dependent.  This  will  be  particularly  true  for  applications 


which  are  re-written  in  fourth  generation  languages  or 
application  generators  which  take  advantage  of  the 
productivity  gains  available  to  systems  developers  using 

such  f  a  c i 1 i t i e  s . 2 

Secondly,  opportunity  23  appears  to  be  of  lesser 
importance  in  light  of  opportunity  37,  which  indicates  that 
opportunities  exist  for  long  term  single  vendor 
relationships.  If  such  long  term  relationships  are 
available  and  desirable,  why  worry  about  portability  for  new 
information  resource  acquisitions  during  the  less  than  six 
year  window  of  this  plan?  Are  current,  near  term,  or  future 
NAVSUP  applications  intended  for  life  cycles  in  excess  of 
the  current  15  to  24  year  vendor  hardware  contracts?  Should 
NAVSUP  be  planning  now  to  port  third  or  fourth  generation 
applications  to  the  fifth  or  sixth  generation  machines  that 
will  be  available  at  the  end  of  these  long  term  single 
vendor  relationships? 

In  light  of  these  comments  and  for  purposes  of  this 
document,  opportunity  number  23  will  be  assumed  to  apply 
solely  to  the  functional  area  logic  of  existing  and  new 
COBOL  applications.  All  data  base  access  and  usage  code, 
transaction  monitors,  screen  facilities,  and  fourth 
generation  language  code  will  be  assumed  to  be  non-portable 
and  disposable. 

^See  Appendix  B,  assumption  numbers  21  and  45. 


The  final  comment  on  opportunities  addresses  opportunity 
number  37,  which  discusses  hardware  and  software  contractual 
vehicles  providing  both  technological  refreshment  anc  long 
term  single  vendor  relationships.  The  former  part  of  tnis 
opportunity  poses  no  problem  to  the  authors.  The  latter 
part  stating  the  desire  for  long-term  single  vendor 
relationships  does  require  i  n ter pr e ta t i o n  . 

This  opportunity  seems  to  exist  in  spite  of  the 
increased  emphasis  within  NAVSUP  on  competition  and 
procurement  system  breakouts. 3  Although  there  are  well 
documented  advantages  to  having  a  solid,  long  term 
relationship  with  a  single  hardware  and  software  vendor, 
there  are  Navy  and  non-Navy  ADP  oversight  organizations  and 
committees  that  rank  potential  price  and  performance 
advantages  in  periodically  recompeting  all  or  portions  of 
the  hardware  and  software  environment  higher  than  the 
potential  advantages  gained  through  long  term  single  vendor 
use.  If  required  to  periodically  compete  "portions"  of 
long-term  contractual  vehicles,  this  may  well  mean 
multi-vendor  support. 

For  purposes  of  this  document,  long  term  single  vendor 
relationships  will  be  considered  preferable,  but  both 
contractual  and  physical  facilities  for  integrating  hardware 
and  software  from  multiple  vendors  must  always  be  available 
within  procurement  vehicles.  Each  technological  refreshment 

3NAVSUP  Strategic  Plan  strategy  number  29  applies. 


planned  must  be  "scrubbed"  for  price  ana  performance 
advantages  in  the  marketplace.  This  opportunity  is  furt.ner 
interpreted  to  mean  that  government  controlled  integrating 
facilities  will  be  available  and  used,  if  and  when  price  or 
performance  advantages  can  accrue  to  tne  government  that 
will  not  be  matched  by  existing  single  vendor  contracts. 

Moving  to  the  area  of  assumptions,  of  the  45  listed  in 
Appendix  B,  all  but  three  are  applicable  to  SPLICE  and 
assumed  applicable.  Applicable  assumptions  are  marked  with 
an  asterisk  by  the  assumption  number.  Three  of  these 
assumptions  require  interpretation. 

Assumption  number  14  states  that  off-the-shelf  data  case 
management  systems  and  automated  data  dictionaries  will  be 
used  in  all  major  systems.  For  the  purposes  of  this 
document,  this  is  interpreted  to  include  existing  systems 
which  only  have  minimal  or  no  real  data  base  management 
facilities  (e.g.,  file  systems  such  as  the  Terminal 
Application  Processing  System  ( T  A  P  S ) 4  II  on  TANDEM)  or  with 
passive  data  dictionaries  {e.g.,  TANDEM  Data  Definition 
Language).  This  assumption  will  further  be  interpretea  to 
mean  that  no  in-house  actions  will  be  undertaken  for 
development  of  facilities  of  a  similar  nature. 

Assumption  number  20  is  an  elaboration  on  opportunity 
number  37,  concerning  the  single  vendor  concept.  For 

4  T  AP  S  is  a  product  of  Informatics  General  Corporation. 

It  has  facilities  for  application  management,  communications 
management,  and  data  or  file  management. 


purposes  of  this  document,  the  comments  made  on  opportunity 
number  37  al so  appl y . 

Assumption  number  21  refers  to  the  increased  use  of 
"high  level"  programming  languages  for  ad  hoc  reports, 
queries,  and  the  increased  use  of  application  generators  in 
developing  new  systems.  "High  level"  languages  normally 
refer  to  third  generation  procedural  languages  such  as 
COBOL,  FORTRAN,  or  PL/1  [Ref.  7].  This  document  interprets 
this  assumption  to  refer  instead  to  fourth  generation 
no n- pr oc ed ur al  and  interactive  query  languages. 

Of  the  27  strategies  listed  in  Appendix  C,  18  are 
applicable  to  SPLICE,  and  are  so  indicated  with  an 
asterisks.  Two  comments  on  this  section  are  necessary. 
First,  strategy  number  13  regarding  portable  and  machine 
independent  application  programs  is  duplicative  of 
opportunity  number  23,  which  was  discussed  previously.  If 
this  duplication  is  not  by  design,  one  or  the  other  should 
be  eliminated.  Second,  the  comments  made  to  opportunity 
number  23  also  apply  to  strategy  number  13. 

Ninety-eight  objectives  are  stated  in  the  plan  and 
summarized  in  Appendix  0.  Of  these,  41  are  directly 
applicable  to  SPLICE  and  are  so  indicated  with  an  asterisk 
next  to  the  objective  number.  No  objectives  applicable  to 
this  thesis  require  interpretation. 


F.  SPLICE  PROJECT  PLANNING 


With  the  NAVSUP  Strategic  Information  Systems  Plan  in 
place  along  with  the  authors'  interpretations,  the  next  step 
will  be  an  analysis  of  the  SPLICE  project  in  light  of  this 
plan.  The  path  the  authors  will  take  to  accomplish  this 
effort  is  as  follows.  Following  a  presentation  of  the 
background  of  the  SPLICE  project,  a  "strawman"  set  of  new 
project  goals,  strategies  and  objectives  will  be  proposed. 
These  will  be  based  upon  the  NAVSUP  Strategic  Information 
System  Plan  outlined  above  and  the  capabilities  present  in 
SPLICE  itself  as  outlined  in  the  background  chapter.  Then, 
each  existing  or  potential  SPLICE  project  implementation  or 
application  area  will  be: 

1.  analyzed  in  terms  of  its  intended  purpose  and 
benefits  to  the  corporation; 

2.  analyzed  in  terms  of  migration  need  and  potential  to 
the  Stock  Point  ADP  Replacement  (SPAR)  Project; 

3.  summarized  in  terms  of  how  it  tactically  supports  or 
can  better  support  proposed  SPLICE  objectives, 
thereby  supporting  previously  proposed  project  goals 
and  strateg  ies . 

The  result  of  this  effort  will  be  an  integrated  set  of 
SPLICE  project  goals,  strategies,  and  objectives  that,  along 
with  recommended  changes  to  tactical  initiatives,  will 
reorient  the  project  to  be  more  in  line  with  the  NAVSUP 
Strategic  Information  Systems  Plan,  where  divergence  is 
encountered  or  where  project  capabilities  can  be  used  to 
accomplish  previously  unanticipated  corporate  objectives. 


II.  BACKGROUND 


A.  CHAPTER  OVERVIEW 

Tie  SPLICE  project,  as  it  exists  today,  represents  an 
evolutionary  growth  of  on-line,  distributed  processing  and 
telecommunications  support  within  the  NAVSUP  data  processing 
environment.  At  its  inception  as  a  joint  NAVSUP  and  Navy 
Fleet  Material  Support  Office  (FMSO)  effort,  SPLICE'S  scope 
was  merely  to  lessen  the  impact  of  capacity  and  local 
telecommunications  problems  associated  with  the  stock  point 
Burroughs  medium  systems.  It  was  also  to  provide  a  standard 
local  interactive  processing  capability  and  augment  and 
replace  existing  Burroughs  remote  job  entry  (RJE)  equipment 
[Ref.  8].  In  contrast,  SPLICE  today  has  grown  to  encompass: 

1.  local  high  speed  i n t er - c om pu t e r  communications  for 
process- to- process  interface,  multi-host  access  from  a 
single  terminal,  and  peripheral  resource  sharing; 

2.  a  base  from  which  to  develop  and  deploy  new 
local  and  network  oriented  applications; 

3.  fault-tolerant  application  processing; 

4.  a  medium  to  share  Burroughs  resident  master  files  with 
or  without  directly  accessing  the  Burroughs  hosts; 

5.  the  NAVSUP  communications  system  backbone  including  an 
interface  to  the  Defense  Data  Network  (DDN)  and  non- 
DDN  based  heterogeneous  system  connectivity  for 

i n t ero per ab  i  1  i  ty  ,  horizontally  and  vertically 
throughout  the  logistics  system; 

6.  a  venicle  to  permit  the  use,  replacement,  or 
interface  of  multiple  vendors'  ADP  hardware 
throughout  the  Navy  logistics  system; 


7 .  a  means  of  providing  interim  office  automation,  local 
area  network,  ana  management  productivity  tools  to  tm 
stoc  k  points. 

8.  and  a  orioge  for  transition  to  the  modern  mainframe 
computers  to  be  acquired  by  the  SPAR  Project. 

Tne  key  features  of  SPLICE  which  have  permitted  me 
implementation  of  these  divergent  capabilities  are: 

1.  A  highly  flexible  and  c om pr e he n s i v e  contact  for 
hardware,  software,  maintenance,  training, 
documentation,  and  vendor  support  [Refs.  9  and  10], 
which  includes  technological  refreshment  capabilities; 

2.  A  very  responsive  prime  contractor,  Federal 
Corporation  (FDC),  who  has  taken  great  pains  to 
understand  the  breath  and  potential  of  the  SPLICE 
project  and  has  provided  supplemental  environmental 
software  training,  designs,  and  implementations 
which  enhance  the  open  architecture  and  processing 
capabilities  of  the  project  (e.g.,  SPLICENet  [Ref. 
ii]); 

3.  A  small,  yet  technically  oriented  project  staff  at 
both  NAVSUP  and  FMSO,  who  have  firmly  guided  the 
project  to  achieve  its  stated  objectives; 

4.  A  dedicated  and  well  trained  software  staff  at  the 
NAVSUP  Central  Design  Agency  (CDA),  FMSO,  who  are 
taking  full  advantage  of  the  power,  modularity,  and 
flexibility  of  the  SPLICE  hardware  and  software 
provided  in  the  contract. 

In  order  to  fully  appreciate  the  role  that  SPLICE  can 
play  in  fulfilling  the  goals,  strategies,  and  objectives  of 
both  the  NAVSUP  Strategic  and  Strategic  Information  System 
plans,  it  is  necessary  to  follow  the  growth  in  scope  and 
capabilities  of  this  project.  The  ability  of  the  project  to 
accommodate  change  and  this  growth  in  the  past  demonstrates 
the  projects's  flexibility  and  versatility  in  meeting  the 
ever  changing  demands  of  the  NAVSUP  environment  and  serves 
as  an  indication  of  its  ability  to  meet  future  corporate 


needs.  Tne  following  paragraphs  fulfill  this  role, 
hignlignting  the  above  mentioned  key  features  where 
appropriate. 

B.  EARLY  HISTORY 

The  SPLICE  project  began  in  late  1977  as  the  result  of  a 
FMSO  pr e sen t a t i o n5  to  NAVSUP  concerning  remaining 
deficiencies  of  the  Burroughs  medium  systems  in  the  areas  of 
capacity,  local  telecommunications  support,  interactive 
processing  support,  and  RJE  support  [Ref.  12].  These 
deficiencies  require  explanation  to  provide  an  understanding 
of  the  stock  point  environment  and  the  initially  planned 
role  of  SPLICE. 

The  Burroughs  medium  systems,  then  B3500s,  had 
originally  been  competitively  procured  by  NAVSUP  in  the 
early  1970' s .  These  systems  replaced  earlier  NAVSUP  Uniform 
Automated  Data  Processing  for  Stock  Point  (UADPS-SP) 
hardware  and  software,  which  were  IBM  1410  based  or  IBM 
360/50  systems  emulating  1410  nardware.  In  that  the  IBM 
1410s  were  primarily  batch  oriented  processors,  the  existing 
applications  which  were  to  be  transitioned  to  the  Burroughs 
hardware  were  primarily  batch  oriented.  Transition  to  tne 
Burroughs  nardware  was  to  be  accomplished  with  limited 


5  T  h  i  s  presentation  is  called  within  the  project  the 
SPLICE  "Spaghetti  Bowl  ’itch". 


redesign  or  modernization. 6  This  resulted  in  the  initial 
Burroughs  systems  also  being  primarily  batch  oriented. 

Prior  to  successful  implementation  of  the  transitioned 
UAQPS-SP  applications  throughout  the  stock  points,  botn 
system  limitations  and  neeaea  technological  ennancements 
began  to  manifest  themsel ves  .  7 

The  Burroughs  off-the-shelf  environmental  software  prior 
to  initial  UADPS-SP  implementation  appears  to  have  been 
deficient  in  the  common  services,  audit  trail,  scheduling, 
data  communications,  and  disk  accessing  and  storage  areas. 
Applicable  environmental  software  packages  were,  therefore, 
modified  jointly  through  Burroughs  and  FMSO  to  provide: 

1.  common  services  and  journaling  facilities  (i.e. 

System  Common  Services  Program  (SCSP)  and  other  copy 
routines),  callable  by  application  programs; 

2.  time/volume  host  scheduling,  terminal  security,  and 
a  line  oriented  teletype  terminal  access  system 
(i.e.,  System  Data  Communications  Handler  (SDCH)  )  ; 

3.  and  a  more  dense  record  storage  and  efficient  disk 
accessing  capability  (i.e.,  Block  Random  Access 

M e t hod / H i er a r c h  i  c a  1  Access  Method  (BRAM/HAM)). 


6  T  h  e  UADPS-SP  Mark  I  Autocoder  system  was  converted  to 
COBOL  under  Mark  II.  Other  changes  under  Mark  II  included 
file-level  controls  of  user  data  through  file  naming 
standards,  record-level  user  identification  for 
transactions,  transaction/reconstruct  data,  user  parameters 
via  Systems  Constant  Areas,  and  true  m u 1 t i pr og r amm  i  ng  under 
the  Burroughs  Master  Control  Program. 

^Little  written  information  could  be  found  on  the  early 
history  of  the  Burroughs  UADPS-SP  systems.  A  brief  history 
was  located  in  the  FMSO  UADPS-SP  Executive  Handbook.  The 
authors'  summary  is  based  upon  this  and  upon  discussions 
with  various  NAVSUP  and  FMSO  personnel  who  were  present  at 
the  time. 


These  extensions  to  the  then  commercial  Burroughs  medium 
systems  software,  provided  (JAOPS-SP  capabilities  which  were 
then  considered  "state-of-the-art"  in  terms  of  data 
processing,  while  also  making  the  software  Navy  unique. 

As  time  progressed  into  the  1  9  7  0'  s ,  further  enhancements 
were  felt  necessary  in  the  areas  of  RJE  support  (to  further 
permit  remote  sites  to  share  the  processing  capabilities  of 
stock  point  hosts),  increased  terminal  and  Cathode  Ray  Tube 
(CRT)  terminal  support,  and  finally,  more  extensive  on-line 
terminal  capabilities.  Again,  Burroughs  and  FMSO  rose  to 
the  task  and  developed: 

1.  the  Multiple  Activity  Processing  System  (MAPS)  for 
the  Burroughs  hosts  and  the  Satellite  Access  Monitor 
(SAM)  software  for  remote  Burroughs  B1700  RJE 
minicomputers,  replacing  the  earlier  Multiple  File 
Concept/COPE  software; 

2.  modified  SDCH  to  handle  newer  Burroughs  CRT  terminal 
types  and  increased  the  quantities  of  terminals 
available  to  the  system  through  additional  changes 
to  SDCH  and  the  introduction  of  terminal 
concentrators  (i.e.,  TC3800  series)  and  front-end 
data  communications  processors  (FEPs)  (i.e.,  B  7  7  4  )  ; 

3.  and  modified  SDCH  and  copy  routines  to  permit 
application  use  of  Burroughs  block  mode  CRTs  for  on¬ 
line  screen  oriented  applications. 

As  the  UAOPS-SP  system  continued  to  mature,  the  FMSO 
env  ironmental  software  engineers,  aided  by  the  Burroughs 
Federal  Systems  Group,  began  to  see  that  additional  changes 
to  the  now  thoroughly  Navy  unique  Burroughs  software,  were 
becoming  more  and  more  complicated,  more  time  consuming, 
more  costly,  and  in  some  cases,  had  reached  the 
architectural  limits  of  the  Burroughs  medium  systems  using 


the  Navy  unique  software.  Concurrent  with  this  realization, 
NAVSUP  was  obtaining  newer,  more  powerful  Burroughs  hosts, 
remotes,  terminal  concentrators ,  and  terminal  hardware  to 
further  relieve  saturation  and  augment  and  furtner  deploy 
UADPS-SP  (e.g.,  B4800s,  B874s,  BISOOs,  3867s,  CRTs,  etc.). 

The  final  straws  that  "broke  the  camel's  back"  in  terms 
of  making  system  enhancements  came  in  the  late  1970's  with: 

1.  Burroughs  host  capacity  saturation  with  little 
further  vertical  or  horizonal  expansion  believed 
po  s  s  i  b  1  e  ; 

2.  the  advent  of  distributed  interactive  processing  on 
minicomputers; 

3.  and  the  obsolescence  of  existing  MAPS  RJE 
processors . 

The  new  processing  requirements  which  developed  as  a  result 
of  these  three  events  could  simply  not  be  handled  by  the 
existing  systems  or  other  Burroughs  systems  for  which  Navy 
contracts  existed. 

By  the  mid-1970's  the  Burroughs  medium  system  hosts  at 
the  stock  points  were  rapidly  reaching  capacity  saturation 
due  to  a  relatively  constant  5-15%  annual  application  growth 
rate  throughout  the  past  decade.  This  growth  rate  reflected 
enhancements  to  existing  applications,  the  introduction  of 
new  applications,  as  well  as  a  yrowing  change  in  user 
processing  methodology.  Many  of  these  new  applications  haa 
passed  the  stage  of  using  merely  on-line,  block  mode 
processing  and  now  required  interactive  communications  with 
users.  The  only  method  to  even  simulate  interactive 
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processing,  which  was  gaining  increased  use  in  industry,  on 
the  Burroughs  medium  systems  was  to  make  applications  memory 
resident  and  setting  their  job  scheduling  and  execution 
parameters  at  their  minimum  values  (i.e.,  time  0,  volume  1). 
Such  settings  permitted  rather  rapid  execution  of  these 
privileged  applications,  at  the  expense  of  all  other  on-line 
applications  and  batch  processing. 8  This  option  could  only 
be  used  selectively,  due  to  the  virtual  monopolization  of 
system  resources  this  mode  of  processing  required.  Such  use 
could  not  accommodate  the  interactive  needs  of  all  newly 
pi anned  appl ications . 

At  the  largest  stock  points,  host  configuration  up¬ 
grades  had  reached  the  top  of  the  line  compatible  Burroughs 
medium  system  model,  the  B4800,9  and  were  already  being  used 
in  d ual - proces sor  configurations.  Therefore,  vertical 
expansion  was  not  believed  possible.  At  that  time  also,  a 
dual  processor  configuration  (referred  to  as  "2-by")  was 
considered  the  maximum  possible  for  processing  e f f i c  i  e n c y  .  1  0 
Some  horizontal  expansion  could  be  undertaken  (i.e.,  the 

8s imul taneous  on-line  and  batch  processing  at  stock 
point  sites  is  often  accomplished  today  by  splitting  the 
Burroughs  hosts.  On-line  processing  is  accomplished  on  a 
"primary"  processor  with  the  majority  of  batch  processing 
accomplished  on  a  "secondary"  processor.  Both  processors 
share  files. 

^The  introduction  of  the  B4900  in  19S4  provided  a  new 
path  of  vertical  expansion  not  previously  anticipated. 

l^In  1984,  the  Burroughs  Federal  Systems  Group  under 
FMSO  direction  also  developed  an  efficient  "3-by"  B4800 
configuration  which  was  deployed  at  NSC  Norfolk. 
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introduction  of  multiple,  independent,  2 -by  systems)  where 
conditioned  computer  room  space  was  available  and  where 
sufficiently  large  applications  could  De  isolated  on  tnese 
separate  systems.  However,  the  practical  implementation  of 
this  approach  was  limited. 

A  further  complicating  factor  was  also  at  play  here. 
NAVSUP  was  beginning  to  face  questions  from  Navy  and  non- 
Navy  oversight  organizations  as  to  why  competition  was  not 
being  used  for  these  UADPS-SP  hardware  enhancements.  Even 
though  the  initial  Burroughs  contract  had  been  competitive 
and  software  compatibility  issues  abounded,  some  of  these 
oversight  organizations  felt  that  continued  granting  of 
Delegation  Procurement  Authority  (DPA)  for  tnese  follow-on 
sole  source  procurements  and  contract  modifications  to 
Burroughs  was  questionable.  Open  competition  was  strongly 
encouraged.  Therefore,  NAVSUP  was  rapidly  facing  an  "in 
extremis"  position  concerning  capacity,  particularly  with 
the  advent  of  the  requirement  for  interactive  processing, 
and  simultaneously  being  "pushed"  into  open  competition. 

Since  horizontal  and  vertical  expansion  within  the 
Burroughs  hosts  was  effectively  precluded  and  open 
competition  encouraged,  the  logical  step  was  for  NAVSUP  and 
F M  SO  to  look  to  moving  additional  growth  and  interactive 
oriented  a pp 1 i c a t i o n s 1 1  off  the  Burroughs  hosts  entirely  and 

^Nineteen  application  or  application  support  areas  were 
identified  in  the  supporting  documentation  to  tne  SPLICE 
Automated  Data  Systems  (ADS)  Plan. 


onto  otner  less  restrictive  systems  which  would  require  only 
minimal  Burroughs  interaction.  The  advent  of  the 
minicomputer  provided  the  means  to  accomplish  this. 

The  minicomputer  revolution  brought  the  ability  for  the 
Navy  to  competitively  acquire  numerous,  relatively  cheap 
hardware  suites  from  multiple  vendors,  along  with  software 
that  could  significantly  reduce  application  development 
time.  This  approach  had  already  been  used  by  several  System 
Commands, 12  who  used  FMSO  as  their  CDA  on  a  project  basis, 
and  who  had  obtained  Interdata  (ID)  7/32  minicomputer 
hardware  and  software  for  their  new  projects. 

On  the  positive  side,  this  approach  was  seen  by  NAVSUP 
as  an  interim  solution  to  both  the  capacity  and  interactive 
processing  problems  discussed  above.  On  the  negative  side, 
nowever,  each  additional  brand  of  minicomputer  obtained 
would  require  access  to  the  rapidly  saturating  Burroughs 
hosts  on  both  a  process  and  terminal  transaction  ( e . g .  , 
pass-through  to  the  Burroughs)  basis.  Additionally,  these 
new  hardware  suites  often  supported  vendor  unique  terminal 
types  and  non-Burroughs  compatible  data  communications 
packages.  The  possibly  of  having  to  uniquely  interface  a 
large  number  of  "foreign  hosts"  to  the  Burroughs  hosts  via 
ever  growing  data  communications  changes  in  SDCH  appeared 

^Examples  are  NAVSEASYSCOM  with  the  TRIDENT  LOGISTICS 
Data  System  (TRIDENT  LDS),  NAVAIRSYSCOM  with  the  Naval  Air 
Logistics  Command  Information  System  (NALCOMIS)  and  the 
Comptroller  of  the  Navy  (NAVCOMPT)  with  the  Integrated 
Disbursing  and  Accounting  systems  (IDA). 
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prohibitive,  regardless  of  the  capacity  relief  provided  by 
these  new  minicomputers. 

It  was  at  this  time  in  December  1977  that  the  "Spaghetti 
Bowl"  pitch  was  made  to  NAVSUP  at  FMSO.  This  pitch 
highlighted  the  above  mentioned  problems,  with  particular 
emphasis  on  the  difficultly  involved  in  interfacing  many 
brands  of  minicomputers  to  the  Burroughs.  This  meeting  also 
provided  a  r  ec  ommend  a  t  ion  for  resolution:  SPLICE. 

It  was  proposed  that  a  SPLICE  project  should  be 
undertaken  to  provide  a  standard  hardware  and  software 
minicomputer  system  for  all  new  UADPS-SP  interactive 
application  systems.  This  standard  system  would  be 
interfaced  via  land  line,  data  communications  to  the 
Burroughs  hosts.  Since  this  system  would  be  used  by  all  new 
NAVSUP  approved  applications  requiring  interactive 
processing,  only  one  additional  minicomputer  data 
communications  (i.e.,  SDCH)  interface  would  be  required. 

The  overhead  which  this  additional  interface  might  cause 
would  be  off-set  by  moving  Burroughs  terminals  and 
downloading  many  of  the  terminal  oriented  SDCH  functions  to 
SPLICE,  providing  some  Burroughs  capacity  relief. 

Additional  capacity  relief  could  also  be  provided  if 
existing  Burroughs  mainframe  applications  would  download 
their  on-line  transaction  edit  and  validation  functions  to 
the  SPLICE  minicomputers.  Finally,  it  was  proposed  that  a 
functionally  equivalent  form  of  MAPS  SAM  software  be  ported 


to  SPLICE,  and  when  completed,  use  SPLICE  systems  to  solve 
the  obsolescence  problem  of  the  existing  Burroughs  B1700 
MAPS  RJE  processors. 

This  proposal  potentially  resolved  the  majority  of 
NAVSUP's  recognized  saturation,  interactive  processing,  and 
obsolete  equipment  problems,  on  an  interim  basis,  until  the 
follow-on  SPAR  project  could  be  undertaken.  The  only 
remaining  issue  was  for  which  minicomputer  hardware  and 
software  to  solicit.  This,  too,  was  resolved  at  the 
December  meeting.  FMSO's  current  investment  in  ID  7/32 
software  development,  both  application  oriented  (using  TAPS) 
and  environmental  (which  developed  into  TRIDENT  Network 
Control  Processor  (NCP)  and  Integrated  Network  Software 
(INS)  for  Burroughs-ID  access)  essentially  resolved  the 
issue.  SPLICE  would  be  developed  and  deployed  on  ID  7/32 
hardware,  obtained  via  a  brandname  or  equal  procurement. 

FMSO  would  standardize  UADPS-SP  and  related  minicomputer 
application  development  on  this  hardware  using  TAPS  and 
develop  additionally  required  environmental  and  MAPS  RJE 
Burroughs  data  communications  interfaces.  Thus,  any 
minicomputer  application  currently  under  design  or  planned 
by  NAVSUP  and  FMSO  could  be  designed  for  and  developed 
immediately  on  existing  ID  7/32  hardware,  later  transitioned 
to  SPLICE,  and  be  deployed  with  little  or  no  modifications. 

Following  several  contractor  studies  on  the  proposal  and 
a  meeting  with  Naval  Data  Automation  Command  (NAVDAC) 


representatives  to  discuss  the  initiative,  the  SPLICE 
project  was  formally  announced  on  14  July  1978  [Ref.  13]. 
Then,  NAVSUP  "moved  out  smartly"  to  execute  SPLICE, 
anticipating  a  short  hardware  acquisition  and  software 
development  time  window. 13  Steps  taken  included  assignment 
of  a  NAVSUP  project  officer,  formal  tasking  to  FMSO  for 
further  concept  design  [Ref.  14],  assuming  use  of  ID 
hardware  and  TAPS,  and  the  preparation  of  an  agency 
procurement  request  ( APR) /granti ng  of  DPA  for  the 
acquisition  of  50  ID  7/32  minicomputers  [Ref.  15].  From  all 
indications,  it  appeared  to  NAVSUP  that  SPLICE  would  be 
available  for  deployment  by  mid  1979,  prior  to  completion  of 
tentative  applications. 


C.  PROJECT  EVOLUTION 

By  December  1978,  these  original  SPLICE  plans  fell  under 
close  re-evaluation.  Numerous  factors  necessitated  this: 

1.  Although  significant  price  advantages  were  available 
in  minicomputer  Central  Processing  Units  (CPUs), 
these  advantages  did  not  extend  to  peripherals  such 
as  disks,  tape  drives,  and  printers.  The  need  to 
share  high  cost  peripherals  in  collocated  systems 
was  recognized. 

2.  Many  of  the  peripherals  on  the  Burroughs  hosts 
themselves  required  replacement  and  had  top 
priority.  There  would  be  significant  cost  savings 
if  Burroughs  peripherals  (e.g.,  CRTs)  could  be 
shared,  to  some  extent,  from  SPLICE. 

3.  Advances  in  local  and  long-haul  telecommunications 
were  taking  place  in  industry  and  within  the 

13yhe  short  software  development  window  was  not 
concurred  with  by  FMSO. 


Department  of  Defense  (DOD).  These  included 
advanced  terminal  and  host  protocols,  new  more 
powerful  terminals,  and  AUTODIN  11.14  UADPS-SP, 
even  with  SPLICE  implemented  on  the  ID  7 / 3  2  s ,  couIg 
not  take  advantage  of  these. 

4.  Land  line  data  communications  among  collocateo 
processors  was  relatively  slow  and  appeared  unaole 
to  meet  all  the  new  applications  response  time  anc 
throughput  r eq u i r em en t s .  High  speed  inter-computer 
communications  on  incompatible  systems  was  now 
possible  [Ref.  16]  and,  if  implemented  successfully, 
could  serve  as  a  SPAR  transition  strategy. 

5.  Tne  ID  7 / 3  2  s  proved  not  to  be  the  "savior"  as  once 
envisioned.  Memory  limitations  (i.e.,  1  MEG),  lack 
of  system  expandability  to  meet  surge  or 
mobilization  requirements,  and  limitations  on  the 
number  of  terminals  which  could  be  supported  were 
evidenced  even  in  the  FMSO  development  arena.  These 
limitations,  when  extrapolated  to  operational  sites, 
indicated  an  inability  to  handle  peak  processing 
loads.  Worse  then  that,  hardware  and  software 
reliability  of  these  systems  was  low  and  seen  as 
unable  to  support  "up-time"  requirements  of  the  new 
interactive  and  CRT  oriented  applications. 15 

6.  The  estimated  number  and  sizes  of  planned 
applications  along  with  an  emerging  requirement  to 
expand  the  number  of  MAPS  RJE  sites  could  not  be  met 
with  a  mere  50  ID  7/32  minicomputers. 

The  combined  effect  of  these  factors  lead  the  NAVSUP  and 

FMSO  SPLICE  personnel  to  conclude  that  the  original  plans 

for  SPLICE  would  not  produce  a  system  which  could  meet  the 

needs  of  UADPS-SP  through  even  the  1980s.  It  was  necessary 

for  SPLICE  to  change  to  accommodate  these  new  requirements. 

1  4  A  U  T  0  D  I  N  II  was  subsequently  replaced  by  the  DDN. 
SPLICE  support  for  DDN  was  later  required  due  to  this 
repl acement. 

15The  use  of  "not"  stand-bys  by  TRIDENT  LDS  and 
processor  upgrades  to  larger  PE  minicomputers  in  other 
applications  temporarily  reduced  the  short-run  impact  of 
these  events,  but  could  not  resolve  them. 


By  May  of  1979,  NAVSUP  cancelled  the  original  SPlICE 
design  tasking  to  FMSO  in  favor  of  a  competitive  procurement 
for  " f a u 1 1- to  1 er an t "  ,  modular,  expandable,  interactive 
processing,  and  communications  oriented  system  Hardware  ana 
software,  which  included  an  AUTODIN  II  interface  as  well  as 
a  high  speed  local  computer  network  (LCN).  The  size  of  tne 
acquisition  also  increased  from  50  processing  systems  to  "2 
to  6  processor  systems"  per  site,  at  62  sites,  orderaole 
totally  on  a  requirements  basis.  In  February  1980,  the 
NAVSUP  request  for  DPA  for  the  ID  7 / 3 2 s  was  formally 
withdrawn  [Ref.  17]. 

Although  the  NAVSUP  and  FMSO  SPLICE  project  teams 
attempted  to  recover  from  tne  time  loss  incurred  due  to  this 
change  of  direction,  other  environmental  factors  worked 
against  them.  Only  a  brief  summary  of  these  factors  is 
presented  below.  A  complete  documentary  history  of  these  is 
available  in  [Ref.  18]. 

New  requirements  for  ADP  project  management  and  control 
resulted  in  a  lengthy  ADS  Plan  development  cycle  with  an 
equally  long  approval  process.  A  new  APR  had  to  be 
generated,  which  was  challenged  at  the  NAVDAC  level  and 
subsequently  modified  to  cover  the  eventual  replacement  of 
all  MAPS  R •  1 E  equipment  and  Burroughs  B  7  7  4  /  8  7  4  front-end 
processors.  Funding  profiles  were  dramatically  changed  due 
to  tne  additional  hardware  requirements.  A  Graft 
ompetitive  solicitation  jocument  had  to  be  prepared  as 


required  by  the  Automated  Data  Processing  Selection  Office 
(ADPSG).  Application  processing  profiles  and  wor<load  data 
had  to  be  collected  in  support  of  site  sizing  and 
oenchmarking  efforts.  In  the  middle  of  all  this,  the 
project  was  required  to  transition  to  Life  Cycle  Management 
(LCM)  control,  resulting  in  further  delays  due  to 
documentation  changes,  reviews,  and  new  approvals. 

The  net  effect  of  all  these  changes  was  a  delay  of  over 
27  months  for  the  SPLICE  project  (to  April  1981),  just  to 
get  a  Source  Selection  Evaluation  Board  established  [Ref. 
19],  so  that  an  active  competitive  procurement  could  be 
undertaken.  The  competitive  procurement  process  itself  took 
an  additional  19  months,  and  finally  resulted  in  the 
contract  with  FDC  for  TANDEM  Non-Stop  TXP  systems.  Network 
Systems  Corporation  HYPERchannel  products,  and  associated 
system  software  and  support  on  17  November  1983. 

0.  SPLICE  DESIGN 

As  might  be  expected  during  the  46  months  from  the 
decision  to  openly  compete  f  -  SPLICE  to  contract  award 
UADPS-SP  hardware,  the  stock  point  application  mix  to  be 
supported,  the  specific  system  support  r e q u  i  r em en t s  ,  and  the 
FMSO  env i ronmen ta 1  designs  continually  changed.  UADPS-SP 
could  simply  not  wait  for  SPLICE,  and  SPLICE  was  required  to 
accommolate  all  changes. 

New  hardware  continued  to  be  added  to  UADPS-SP  in  an 
attempt  to  overcome  immediate  processing  shortcomings  and 


project  requirements.  Additional  64800s  were  aadec  to  the 
inventory  at  larger  sites  under  an  interim  CPU  upgrade 
project,  replacing  earlier  models  wnich  were  reallocated  to 
smaller  sites.  Starting  in  1985,  34900  hosts  were  also 
added,  following  an  13  montn  planning  effort.  A  Peripheral 
Replacement  Project  replaced  older  Burrougns  disk,  tape,  and 
printer  units.  This  same  procurement  vehicle  obtained  more 
modern  Burroughs  terminal  c o nc en t r a  to r s  (i.e.,  C  P  9  4  0  0  s  anc 
CP9500s).  Leases  and  buys  of  B1900  minicomputers  replaced 
older  B1700  and  B1800  systems.  New  Burroughs  and  compatible 
terminals  (e.g.,  MT980  series,  Delta  Datas,  etc.)  and 
printers,  as  well  as  m  i  c r oc ompu ter s  were  added  at  sites  in 
large  numbers.  Many  Perkin-Elmer  (PE)  3200  series  hosts 
replaced  older  10  7/32  systems.  And  finally,  the  Naval 
Integrated  Storage  and  Retrieval  System  (NISTARS)  project 
had  required  that  an  interface  of  TANDEM  Non-Stop  1 1 s  to  the 
Burroughs  system  be  developed.  SPLICE  now  nad  to  also 
accommodate  these  changes. 

All  four  of  the  applications  which  were  to  nave  oeen 
totally  application  resident  on  SPLICE  had  been  developed 
ana  deployed  on  other  hardware.!®  The  remaining  15 

!®IDA  and  the  Navy  Automated  Documentation  System 
(NAVADS)  were  successfully  developed  and  deployed  on  PE 
hardware  using  TAPS.  The  Automation  of  Procurement  and 
Accounting  Data  Entry  System  (APADE)  had  been  developed  and 
prototyped,  but  was  not  aeployed  in  its  PE  form.  The 
Receipt  Improvement  Program  (RIP),  renamed  Application  B 
Enhanced  (ABE),  had  been  successfully  developed  and  deployed 
on  Burroughs  terminal  concentrators  with  some  core  resident 
applications  on  the  Burroughs  hosts. 


applications  which  SPLICE  was  to  support  on  a  pass-tnroug.n 
basis  to  Burroughs  or  for  edit  and  validation  purposes  nad 
either  oeen  developed  and  deployed  on  Burroughs  or  ID 
equipment,  deferred  indefinitely,  or  were  cancelled. 17 
Althougn  SPLICE  was  still  required  to  function  as  a  base 
from  which  to  develop  other  new  applications  or  the 
functional  transition  of  any  existing  Burroughs  application 
or  part  thereof,  there  were  now  no  immediate  applications  in 
waiting  for  SPLICE. 

With  the  completed  implementation  of  many  of  the 
original  applications  SPLICE  had  planned  to  support,  there 
appeared  to  be  little  urgency,  from  an  application  point  of 
view,  to  move  existing  terminal  processing  to  SPLICE. 18 
SPLICE  project  personnel  felt,  therefore,  that  system 
support  requirements  should  be  migrated  from  an  emphasis  on 
deployment  and  usage  services  for  the  original  19 
applications  to  an  emphasis  on  generalized  communications 
servicesll  for  any  application  and  for  projected  stock  point 
terminal  additions.  This  change  in  emphasis  was  pursued  but 

^Transportation  Operational  Personal  Proper  ty  Standard 
System  ( TOPS)  . 

l^Tne  exception  being  Transaction  Ledger  On  Disk  (TLOD). 

l^These  generalized  communications  requirements 
included:  support  for  every  terminal  type  used  within  the 
NAVSUP  community;  local  computer  network  interfaces  to 
Burroughs,  IBM,  PE,  TANDEM,  and  Univac;  data  communications 
interfaces  to  I8M  hosts;  DON  interface  for  i  n t e r o pe r ab  i  1  i  t y  ; 
inter-SPLICE  networking  capabil  ities;  and  horizontal  and 
vertical  logistics  system  connectivity,  exclusive  of  DDN. 


resulted  in  SPLICE  having  to  provide  its  own  initial 
environmental  capacity  off-load  from  the  Burroughs  to  make 
up  for  the  initial  additional  workload  that  the  LCN 
interface  would  add  to  the  Burroughs,  assuming  few  Burrougns 
terminals  from  the  existing  inventory  would  be  moved  to 
SPLICE  on  day  one.  Therefore,  a  plan  was  developed  that 
would  permit  the  off-load  of  the  Burroughs  TRANSRECON 
(journal  facility)  to  SPLICE  using  the  LCN  to  provide 
initial  capacity  relief. 

With  the  journal  facility  available  on  SPLICE,  a  means 
was  now  present  to  replicate  Burroughs  master  files  on 
SPLICE  and  keep  them  current  on-line,  once  initial  file 
loads  were  accomplished.  Assuming  this  facility  was 
available,  new  applications  were  then  identified  [Ref.  20] 
that  could  use  these  replicated  files  on  an  immediate 
inquiry  basis  and  for  ad  hoc  batch  reports,  relieving  up  to 
2  hours  of  processing  time  a  day  on  the  Burroughs  hosts. 20 
The  transitioning  of  Burroughs  End-of-Day  application 
processing  to  SPLICE  also  became  a  possibility,  providing 
the  potential  for  even  further  Burroughs  capacity  relief. 
With  the  potential  for  significant  Burroughs  capacity 

20To  meet  this  requirement,  the  SPLICE  Information 
Center  concept  was  born.  This  Information  Center  capability 
revived  interest  in  moving  other  Burroughs  terminals  to 
SPLICE.  With  this  capability,  a  single  terminal  could 
access  Replicated  Files  on  SPLICE  very  rapidly,  or  use 
"pass-thru"  facilities  on  SPLICE  to  access  non-replicated 
Burroughs  files  or  programs. 


paybacks,  this  group  of  "download  projects"  was  then  added 
to  the  SPLICE  requirements  list  [Ref.  21]. 

The  SPLICE  long-term  commitments  to  the  originally 
planned,  four  wholly  resident  applications  also  remained 
intact.  Although  these  applications  naa  been  developed  and 
deployed  on  other  hardware,  the  limitations  that  had 
necessitated  SPLICE'S  change  in  direction  in  1979  were 
adversely  effecting  them  now.  These  applications  required  a 
"transparent"  transition  vehicle  to  SPLICE.  This  was  to  be 
accomplished  through  the  porting  of  TAPS  to  SPLICE. 21  One 
addition,  however,  was  added  to  SPLICE  support  requirements 
in  this  arena.  A  text  processing  capability  was  emerging  as 
a  requirement  for  the  under  redesign  APADE  application. 

The  original  FMSO  SPLICE  environmental  designs  remained 
in  a  state  of  flux  by  trying  to  keep  up  with  the  moving 
SPLICE  "target."  As  previously  indicated,  the  original 
designs  for  SPLICE  on  the  ID  7/32  were  abandoned.  The 
competitive  solicitation  process  and  the  six  month  window 
mandated  for  completion  of  initial  SPLICE  capabilities  after 
contract  award  required  that  design  and  development  be 
undertaken  without  specifically  knowing  the  target  hardware 
or  software.  This  was  a  particular  problem  on  the 
environmental  interface  software  side,  as  "hooks"  into  the 
procured  "off-the-shelf"  environmental  software  would  be 

2lA  similar  porting  of  TAPS  had  been  accomplished  by  the 
Army  for  the  VIABLE  project. 


required.  Generic  functional  and  system  designs  were 
developed,  in  a  phased  approach,  and  continually  modified  as 
requirements  changed. 22 

To  accommodate  the  numerous  SPLICE  r equ i r em e n t s  ,  the 
project  was  split  into  phases.  Tne  phases  of  SPLICE  finally 
solidified  as  follows  [Ref.  22]: 

1.  In  the  first  phase  of  the  development,  SPLICE 
hardware/ so ftware  systems  were  to  provide  enhanced 
interactive  processing  for  stock  point  systems  using 
either  the  procured  Transaction  Processing  Systems 
(TPS)  or  TAPS.  Selected  UADPS-SP  applications  were 
to  migrate  to  the  SPLICE  hardware  for  partial  or 
total  processing  support  depending  on  the 
application,  interactive  requ  irements ,  processing 
sites  and  funding  availability.  Processing  was  to 
take  place  along  the  local  SPLICE  multi -  vendor 
terminal  and  LCN  networks,  thereby  beginning 
possible  reduction  of  telecommunications  workloads 
on  the  non-SPLICE  computers  and  permitting  shareable 
resources.  A  basic  interface  to  the  DDN  would  also 
be  prov  id  ed  . 

2.  In  the  second  phase  of  SPLICE  implementation  of  RJE 
processing  improvements  were  to  be  developed  on 
SPLICE  nodes  and  made  available  to  the  remote  stock 
point  locations.  Software  enhancements  and  SPLICE 
hard  war e/ so f twar e  configurations  were  to  improve  and 
expand  remote  processing  methods. 

3.  The  third  phase  of  the  SPLICE  project  was  to  establish 
a  fully  i n t ero per ab 1 e  network  capability  under  SPLICE 
using  the  DDN  service  protocols.  £3 

4.  In  the  final  and  fourth  phase,  the  LCN  interfaces 
were  to  be  expanded  to  support  other  host  systems 
and  to  provide  the  framework  for  SPAR. 


22[)uring  this  period,  the  SPLICE  Requirements  Statement 
was  modified  twice,  and  the  SPLICE  Functional  Description 
and  System  Specifications  were  each  modified  three  times. 

2  3  f  h  i  s  ,  along  with  additional  non-DDN  functionality,  is 
currently  called  SPLICENet. 


At  the  end  of  these  phases,  a  SPLICE  configuration  woul 
provide,  at  a  minimum,  support  of  the  following  stock  point 
AOP  or  telecommunications  functions: 

1.  Conversational  (interactive)  program  support, 
including  text  processing; 

2.  Remote  job  entry  services  (including  remote 
input/output  queue  management); 

3.  Queued  support  of  transaction  input/output 
terminals; 

4.  Operating  system,  process  and  file  Integrity  for 
high  system  availability; 

5.  No  n-d  i  sr  upt  i  v  e  r  ec  o  n  f  i  g  ur  a  t  i  o  n  /  ex  pa  n  s  i  o  n  ; 

6.  Location  independent  process-to-process 
c  omm  un i c  a t i on  s  ; 

7.  Modular  expansion  of  hardware  and  software; 

8.  Local  screen  management  support  for  local  display 
terminals  connected  to  remote  processes; 

9.  User  and  process  routing  in  support  of  a  distributed 
transaction  processing  environment. 

D.  SPLICE  DEVELOPMENT 

Actual  SPLICE  Phase  I  prototype  interface  software 
development  based  on  FMSO  design  documents  began  in  the 
summer  of  1981.  This  prototype  software  was  written  in 
PASCAL24  and  developed  on  a  pair  of  interconnected  PE  3244s 
Its  purpose  was  to  test  design  concepts  and  reduce  the 
learning  curve  when  the  final  target  system  was  identified. 
Similar  efforts  were  undertaken  using  a  R&D  funded 
HYPERchannel  system.  Although  it  had  been  hoped  that 

24This  language  was  selected  for  portability. 


software  developed  from  these  efforts  would  De  ported  to  the 
final  SPLICE  hardware,  in  the  final  analysis,  it  only  served 
to  assist  in  identifying  problems  and  shaking  out  the 
design.  No  software  was  deployed  from  tnese  initiatives. 

FMSO  SPLICE  software  design  and  development  resources 
were  used  extensively  during  this  time  on  the  solicitation 
effort,  particularly  in  the  benchmarking  and  operational 
test  areas.  This  dual  use  of  resources  (development  and 
solicitation)  reduced  the  development  output  of  the  FMSO 
SPLICE  team,  but  resulted  in  an  early  familarity  with  the 
potential  hardware  and  software  and,  thus,  reduced  the 
development  learning  curve. 

It  was  not  until  late  within  the  procurement  process  (in 
June  1983  when  only  two  offerors  remained,  both  proposing 
TANDEM  and  HYPERchannel  products)  that  TANDEM  based  SPLICE 
development  commenced  in  earnest.  The  first  commercial 
TANDEM  training  was  obtained  at  this  point  in  identified 
off-the-shelf  software  products,  to  further  reduce 
environmental  and  application  development  lead  time  once  the 
contract  was  awarded.  Following  training,  live  development 
work  began  on  the  SPLICE  environment  software  (i.e., 
Burroughs  P r e- P r oc e s so r ,  the  File  Replication  software,  and 
the  Navy  interfaces  to  HYPERchannel). 

Since  TANDEM  did  not  corporately  support  PASCAL  at  that 
time,  two  contractual  software  development  efforts  were 
required.  The  first  was  undertaken  to  develop  a  TANDEM 


based  PASCAL  compiler,  so  that  TAPS,  recently  re-written  in 
PASCAL  on  a  PRIME  host  and  renamed  TAPS  II,  could  be  porteo 
to  the  new  hardware  in  order  to  reduce  the  transition  time 
of  two  of  the  four  original  SPLICE  resident  applications 
[Ref.  23].  Add  itional ly,  contractual  efforts  for  the 
porting  of  TAPS  II  itself  to  SPLICE  were  completed  [Ref. 

24]  . 

When  the  SPLICE  acquisition  contact  was  signea  in 
November  1983,  SPLICE  Phase  I  development  was  in  full 
production  mode  on  the  environment  side  and  in  training  mode 
on  the  application  side.  FDC  entered  the  picture  at  this 
point,  providing  on-site  FMSO  support,  additional  training, 
and  completing  their  Security  Access  System  (SAS),  System 
Monitor  (SMON),  and  universal  terminal/ printer  interface 
mapping  (TMAP)  software.  When  the  Burroughs  HYPERchannel 
software  package  (i.e.,  Burroughs  NETEX)  provided  from  the 
contract  failed  to  perform  in  an  operational  environment, 

FDC  also  provided  assistance  to  FMSO  in  development  of  a 
local  TANDEM-to-Burroughs  (TABU)  HYPERchannel  software 
package.  Similar  FDC  assistance  was  provided  to  the  initial 
SPLICE  developing  applications:  Transaction  Ledger  on  Disk 
and  Replicated  File  Inquiries. 25  Co nc ur r en 1 1 y  ,  contractor 
development  was  underway  on  the  Inventory  Location  Audit 
Program  application. 

25ihese  applications  used  the  TANDEM  native  mode 
transaction  processing  system,  PATHWAY.  TAPS  was  reserved 
solely  for  the  transition  of  IDA  and  NAVADS. 


All  development  work  for  the  Phase  I  SPLICE  prototype 
site,  Naval  Regional  Data  Automation  Command  (NARDAC) 
Jacksonville,  supporting  Naval  Supply  Center  (NSC) 
Jacksonville,  was  completed  in  the  late  summer  of  1984. 
Implementation  of  Phase  I  of  SPLICE  at  this  site,  including 
the  initial  applications,  was  completed  on  2  November  1984. 
This  successful  prototype  permitted  the  SPLICE  project  to 
submit  their  System  Decision  Paper  III  (SDP  III)  document 
for  system  approval  and  thus  receive  authority  for 
subsequent  system  deployment,  including  follow-on 
development  phases,  capabilities,  and  additional 
applications  [Ref.  25]. 

The  SPLICE  project  is  in  the  process  of  implementing 
Phase  I  throughout  the  stock  point  community.  Co nc u r r en tl y  , 
work  is  underway  for  subsequent  phases  and  applications. 

From  this  rather  lengthy  background  chapter,  it  should  be 
clear  that  the  SPLICE  project  has  grown  significantly  over 
the  years  in  both  size  and  potential  to  meet  the  ever 
changing  needs  of  the  NAVSUP  stock  point  environment.  With 
this  background  established,  it  is  now  possible  to  see  how 
the  current  and  projected  SPLICE  capabilities  listed  at  the 
beginning  of  this  chapter  can  be  used  to  facilitate  overall 
NAVSUP  corporate  plans,  through  revised  SPLICE  project 


III.  PROPOSED  SPLICE  PROJECT  PLANS 


A.  CHAPTER  OVERVIEW 

I  .o  the  introduction  to  this  document,  definitions  were 
provided  for  the  terms  goals,  strategies,  and  objectives. 

For  emphasis  purposes,  they  are  reproduced  here: 

1.  Goals  -  long  terms  results  that  an  organization  wishes 
to  achieve. 

2.  Strategies  -  means  to  accomplish  goals  by  providing 
corporate  direction  and  intent. 

3.  Objectives  -  immediate  short  run  actions  which 
implement  strategies  and  which  should  be  supported  by 
tactical  initiatives. 

How  these  terms  apply  to  SPLICE  planning  is  the  next  area 
which  will  be  discussed. 

The  SPLICE  SOP  III  document  is  the  current  published 
source  of  SPLICE  project  plans.  Its  orientation  and  format 
is  dictated  by  LCM  guidelines  [Ref.  26].  Since  the  SPLICE 
SOP  III  documentation  pre-dates  both  the  NAVSUP  Strategic 
and  Strategic  Information  System  plans,  its  format  is  not 
directly  comparable  to  the  latter  documents.  For  example, 
the  SPLICE  SOP  III  document  uses  a  hierarchy  of  concepts, 
capabilities,  and  what  are  called  "objectives"  to  describe 
what  are  termed  goals  and  strategies  in  the  latter  plans, 
and  uses  Plans  of  Action  and  Milestones  (POA&Ms)  to  describe 
both  other  immediate  objectives,  similar  to  those  in  the 
latter  plans,  as  well  as  tactical  plans. 


Prior  to  proposing  changes  to  SPLICE  plans  to  oring  them 
into  consonance  with  the  NAVSUP  Strategic  and  Strategic 
Information  System  plans  and  terminology,  it  is  appropriate 
to  present  the  existing  project  plans  for  comparison  and 
analysis  purposes.  To  accomplish  this  a  reorganization  ana 
i n t er pr e t a 1 1  o n  of  some  information  in  the  SPLICE  SDP  III 
document  is  required,  particularly  in  the  area  of 
terminology.  The  following  paragraphs  will  provide  the 
basis  for  this  and  then  propose  revisions. 

B.  PROPOSED  SPLICE  PROJECT  GOALS 

The  goals  of  the  SPLICE  project,  termed  key  objectives 
in  the  SPLICE  SDP  III,  are  promulgated  as  follows  [Ref.  27]: 

1.  Provide  a  nucleus  for  supporting  all  current  and 
future  logistics  data  communications  requirements  by 
consolidating  local  and  long  distance  communications 
into  a  single  integrated  network  using  the  DDN  as  a 
backbone; 

2.  Provide  state-of-the-art  interactive  transaction  and 
distributed  processing  capabilities  to  alleviate  the 
saturation  of  the  installed  computer  base; 

3.  Provide  economic  system  support  and  standard  ization  of 
computer  suites  by  providing  a  general  purpose 
computer  system  to  curtail  the  pr o 1 i f er a t i o n  of 
incompatible  minicomputers  at  UADPS-SP  host  and  remote 
sites. 

In  comparing  these  goals  with  those  of  the  NAVSUP 
Strategic  Information  Systems  Plan  presented  earlier  in  this 
document,  one  major  difference  becomes  apparent.  The 
existing  SPLICE  goals  tend  to  deal  more  with  specific  stock 
point  environmental  ADP  issues  than  long  term  logistics 
system  results  or  benefits  that  could  accrue  to  the  NAVSUP 


corporation  as  a  whole.  This  is  not,  in  and  of  itself,  a 
proolem  in  that  tne  SPLICE  document  preceded  the  other  two, 
but  it  is  now  inconsistent  with  the  format  and  design  of  tne 
senior  level  planning  documents.  In  addition,  however,  tne 
goals  themselves  appear  as  either  not  accomplishable  or 
backward  looking,  in  the  opinion  of  the  authors.  The 
following  paragraphs  will  elaborate  on  this  contention. 

The  first  goal  appears  not  accomplishable  from  several 
aspects,  if  one  takes  the  word  "all"  literally.  First, 
SPLICE  has  an  impact  only  on  a  portion  of  stock  point 
logistics  data  communications  requirements,  when  one 
includes  the  NAVDAC  supported  stock  points  and  emerging 
NAVCOMPT  financial  stock  point  related  systems.  The  NARDAC 
and  Naval  Data  Automation  Facilities  (NARDAF)  activities, 
though  their  sponsor  NAVDAC,  are  pursuing  their  own  Univac 
U1100  DDN  interface  [Ref.  28],  their  own  local  networking 
initiatives,  and  have  never  approved  the  SPLICE  LCN 
interface  to  their  Univac  hosts  [Ref.  29].  The  NAVCOMPT 
I D A F IPS  system  also  includes  its  own  DDN  interface  [Ref. 

30],  its  own  interim  host-to-host  networking  initiative 
using  Burroughs  Network  Architecture  [Ref.  31],  and  was 
never  planned  to  interface  to  the  SPLICE  LCN.  Additionally, 
SPLICE  itself  must  support  non-DDN  based  logistic  data 
communications  requirements  for  Defense  Logistics  Agency 
access  and  interface  to  a  separate  NAVSUP  sponsored 
Inventory  Control  Point  (ICP)  local  and  long-haul  data 


communications  network,  I C  P  T4  e  t  [Ref.  32].  For  these 
reasons,  tnis  goal  of  SPlICE  providing  the  nucleus  for  "all" 
current  ana  future  stock  point  communications  requirements 
appears  to  the  autnors  as  not  accomplishable. 

Moving  to  the  second  goal,  it  appears  to  the  authors  as 
backward  looking,  or  describing  already  completed  events. 
Specifically,  this  goal  appears  to  have  been  already 
accomplished  by  two  events,  with  a  third  event  providing  a 
long  term  resolution.  First,  much  of  the  immediate 
saturation  problem  at  the  stock  points  appears  to  have  been 
resolved  by  the  delivery  of  the  Burroughs  B4900s  to  the 
stock  points  [Ref.  33].  Second,  the  signing  of  the  SPLICE 
contract  itself,  with  subsequent  system  deployment,  provided 
the  processing  capabilities  stated  within  this  goal. 
Additionally,  it  is  in  the  already  completed  and  on-going 
deployment  of  SPLICE  resident  applications  that  additional 
potential  short-run  saturation  problems  can  be  avoided.  The 
third  event,  the  SPAR  project  which  will  shortly  be  awarding 
its  own  long-term  hardware  and  software  contract  for  the 
stock  points,  is  itself  predicated  on  long-term  saturation 
avoidance  [Ref.  34].  In  light  of  these  accomplished  or  near 
term  events,  this  goal  of  providing  processing  capabilities 
to  relieve  stock  point  host  saturation  appears  out  of  date, 
in  that  it  has  been  accomplished,  and  is  no  longer 
a  pp 1 i c  ab 1 e  . 


Finally,  the  third  goal  appears  as  both  not 
accomplishable  and  backward  looking.  It  is  not 
accomplishable  due  to  a  source  outsiae  of  NAVSUP  control: 
NAVCOMPT.  As  NAVSUP  moves  tc  eliminate  n-o-TANDEM 
minicomputers  from  the  stock  points,  NAVCOMPT,  particularly 
with  its  PE  321C  based  NAVSCIPS  project  [Ref.  35],  will  move 
a  small  number  of  more  recent  vintage  PEs  back  in. 26  it  is 
felt  that  this  goal  is  backward  looking  in  that  the 
pr o 1  i  f er a t  i  o n  of  NAVSUP  controlled  no n - B u r r o ug h s  compatible 
minicomputers  at  stock  points  appears  to  have  ceased  with 
the  deployment  of  SPLICE.  Therefore,  this  goal  too  becomes 
questionable. 

In  light  of  the  above,  it  appears  that  a  new  set  of 
goals  for  the  SPLICE  project  is  necessary.  The  following 
goals  are  proposed  based  on  the  NAVSUP  Strategic  Information 
System  Plan  and  the  capabilities  available  within  the  SPLICE 
project  as  outlined  in  Chapter  2  of  this  document: 

1.  Assure  that  SPLICE  fully  supports  the  Material 

Requirements  Determination  Program,  provides  improved 
fleet  support,  and  assists  in  weapons  system  logistics 
support  requirements  by  providing  system  capacity  for 
applications,  a  comprehensive  set  of  local  and 


2 6 1 1  should  also  be  noted  that  at  some  stock  points  the 
Defense  Communications  Agency  (DCA)  will  be  installing  DDN 
Interface  Message  Processors  (IMPs)  of  the  BBN  C30  series. 
This  adds  yet  another  additional  "minicomputer"  to  the  stock 
point  environment,  even  though  they  will  not  be  specifically 
responsible  for  it. 


longnaul  data  c omm un i c a t i o n s  capaoil  ities,  and  office 
auto -nation/ management  support  tools.  { NSI SP27  Goal  1) 

2 .  Assure  that  SPLICE  fully  participates  in  tne  NAVSUP 
Information  Resources  Management  Program  including 
data  administration,  so  tnat  information  is  managed  as 
a  NAVSUP  corporate  resource.  (NSISP  Goal  2) 

3.  Assure  that  on-going  ana  future  SPLICE  initiatives 
provide  security,  data  accuracy,  maximum  modularity 
and  flexibility,  maximum  integration,  and  a  timely 
return  on  investment.  (NSISP  Goal  3) 

4.  Assure  that  SPLICE  project  efforts  result  in  improved 
user  effectiveness,  increased  productivity,  and  better 
use  of  Navy  resources.  (NSISP  Goal  4) 

5.  Ensure  SUP  0472  develops  and  maintains  comprenensive 
SPLICE  strategic  and  tactical  plans,  performs 
effective  budgeting,  and  efficiently  manages  its 
assets  consistent  with  the  overall  NAVSUP  mission  and 
goal s.  (NSISP  Goal  6  ) 

6.  Assure  that  SPLICE  effectively  exploits  new  and 
emerging  information  system  technology.  (NSISP  Goal  7) 

As  can  be  seen,  these  proposed  goals  are  directly 
relatable  to  NAVSUP  Strategic  Information  System  goals  and, 
as  will  be  demonstrated  in  latter  chapters,  are  supportaDle 
from  existing,  planned,  or  potential  SPLICE  and  application 
project  capabilities.  With  these  goals  so  proposed,  the 
area  of  SPLICE  strategies  can  next  be  addressed. 


C.  PROPOSED  SPLICE  PROJECT  STRATEGIES 

The  SPLICE  project  has  specified  in  its  SDP  III  document 
32  project  strategies,  broken  down  into  support,  design  and 
economic  areas,  which  also  happen  to  be  termed  "objectives" 

2^Each  proposed  SPLICE  goal  is  c r o s s - r e f e r en c ed  to  the 
senior  level  plan  by  this  notation.  NSISP  will  be  used  as 
an  abbreviation  for  the  NAVSUP  Strategic  Information  System 


[Ref.  36].  Due  to  their  length,  they  have  been  reproduced 
as  Attac  hment  E . 

Although  these  strategies  are  not  directly  related  to 
the  later  strategies  produced  in  the  NAVSUP  Strategic  and 
Strategic  Information  System  plans,  they  appear  to  be 
comprehensive  and  well  presented. 28  The  major  problems  that 
become  evident  from  these  strategies  are  twofold.  First,  of 
the  32  presented,  14  are  considered  to  De  complete  since 
they  are  either  acquisition  related  or  have  been  accomplisn 
through  SPLICE  Phase  I.  Those  considered  complete  are 
indicated  by  an  asterisks  next  to  the  strategy  number  in 
Attachment  E.  Second,  at  least  tnree  of  the  remaining 
strategies  appear  as  duplicates  or  variations  on  previously 
presented  strategies  (i.e.,  number  20  is  a  variation  on 
number  10  and  numbers  21  and  32  are  variations  on  number  3). 

Using  the  remaining  strategies,  the  NAVSUP  Strategic 
Information  System  Plan,  and  the  SPLICE  capabilities 
outlined  in  Chapter  2  as  a  basis,  a  revised  set  of  SPLICE 
project  strategies  has  been  prepared.  Again  do  to  their 
length,  the  new  strategies  are  provided  as  Attachment  F, 
instead  of  being  presented  here.  As  can  be  seen,  these 
proposed  strategies  are  directly  related  to  both  NAVSUP 
Strategic  Information  System  Plan  strategies  and  to  the 
proposed  SPLICE  project  goals  presented  earlier.  As  such, 

22More  importantly,  they  were  sufficient  to  obtain  SOP 
III  approval. 


they  should  "fit"  better  under  the  NAVSUP  corporate  planning 
umbrella,  resulting  in  greater  impact  and  planning 
cohesiveness  . 

Having  now  proposed  a  new  set  of  SPLICE  project  goals 
and  strategies,  both  directly  related  to  the  NAVSUP 
Strategic  Information  System  plan,  the  area  of  supporting 
objectives  may  now  be  addressed. 

D.  PROPOSED  SPLICE  PROJECT  OBJECTIVES 

The  final  area  of  SPLICE  planning  that  must  be  discussed 
is  that  of  objectives.  From  the  analysis  point  of  view, 
this  is  the  most  difficult  area  to  address  because  what  has 
been  defined  as  objectives  within  this  document  and  in  the 
senior  level  NAVSUP  planning  documents,  is  presented  within 
the  SPLICE  project  supporting  documentation  and  SDP  III 
document  by  a  long  series  of  POA&Ms  [Ref.  37].  For  example, 
the  NAVSUP  SPLICE  project  office  periodically  issues  a 
SPLICE  Milestone  Plan  and  Status  Report.  Within  this 
document  are  16  separate  POA&Ms  covering  all  the  project 
management,  hardware,  and  environmental  software  areas. 
Environmental  software  areas  are  further  delineated  by  FMSO 
maintained  POA&Ms.  However,  the  SPLICE  project  office  is 
not  directly  responsible  for  SPLICE  applications  nor  for 
NAVSUP  wide  telecommunications.  Therefore,  many  additional 
POA&Ms  from  other  codes  within  NAVSUP  must  be  reviewed  for 
SPLICE  application  objectives,  also  supported  by  more 
detailed  FMSO  documents,  and  still  others  for  NAVSUP 


telecommunications  objectives,  which  do  not  appear  to  have 
correspond  i  ng  FMSO  documents. 

Little  purpose  would  be  served  by  reproducing  tnese  many 
documents  as  appendices  to  this  work  or  attempting  to 
summarize  them  here.  An  alternative  approach  was  selected 
wherein  the  authors  reviewed  these  documents,  discussing 
portions  with  applicable  project  managers,  and  ^elected  key 
milestones  to  be  incorporated  into  a  master  list  of  SPLICE 
project  objectives.  The  proposed  master  list  is  provided  as 
Attachment  G  to  this  document. 

In  reviewing  Attachment  G,  several  points  should  be 
noted.  First,  an  attempt  was  made  to  include  objectives  for 
every  major  area  in  which  the  SPLICE  project  is  currently  or 
projected  to  be  working  in,  along  with  several  additional 
areas  being  recommended  by  the  authors  for  adoption  as 
official  SPLICE  objectives.  Secondly,  each  objective  is 
cross-referenced  to  both  applicable  SPLICE  strategies  and 
NAVSUP  Strategic  Information  System  Plan  objectives. 

Finally,  estimated  completion  dates  have  been  proposed,  but 
since  limited  contact  with  the  affected  field  activities  was 
possible  during  the  time  allowed  for  this  work,  these  dates 
must  be  considered  "soft"  and  will  require  further  inputs 
prior  to  actual  adoption. 

Having  proposed  n'ew  SPLICE  project  goals,  strategies, 
and  objectives,  the  areas  of  supporting  tactical  initiatives 
and  programs  can  now  be  addressed  in  the  next  five  chapters. 


IV.  CENTRALLY  MANAGED  SPLICE  SUPPLY  APPLICATIONS 

A.  CHAPTER  OVERVIEW 

Two  major  categories  of  application  programs  exist  at 
the  Navy  stock  points:  FMSO  centrally  designed  and  developed 
applications  and  locally  designed  and  developed 
applications.  Within  these  categories,  six  major  functional 
application  areas  exist:  physical  distribution,  inventory 
management,  stock  point  management,  proc ur em en t / c on tr ac t  i  ng  , 
financial  services,  and  stock  point  services. 

In  this  chapter,  centrally  developed  SPLICE  supply 
applications  in  the  first  three  areas  will  be  addressed  from 
several  aspects.  First,  proposed,  in  design,  and  already 
developed  SPLICE  supply  applications  will  be  presented  in 
terms  of  their  purpose,  including  their  defined  corporate 
support  and  benefit  area(s)  or  potential  for  increased 
corporate  support  and  benefit.  Secondly,  these  applications 
will  be  analyzed  in  terms  of  their  need  and  potential  for 
migration  to  the  SPAR  Project.  Finally,  it  will  be  shown 
how  each  application  tactically  supports  or  can  be  made  to 
better  support  the  proposed  SPLICE  objectives. 

While  performing  this  last  effort,  recommendations  will 


be  made  for  changes  to  these  tactical  or  application 
programs  to  enable  them  to  provide  greater  support  or 
benefit  to  the  "NAVSUP  c o r por a t  i  o n . "  These  r ec omm e nd a t  i  o n s 


will  tend  to  focus  more  on  the  data  processing  or 
information  system  areas  rather  than  on  the  functional 
areas.  This  is  necessary  because  the  authors  are  not,  and 
do  not  wish  to  imply  that  they  are,  qualified  systems 
analysts  in  any  of  the  functional  areas  which  SPLICE 
addresses,  but  do  understand  the  basic  business  processes. 

With  this  preview  in  mind,  the  presentation  of  SPLICE 
physical  distribution,  inventory  management,  and  stock  point 
management  application  areas  will  next  be  undertaken. 

B.  SPLICE  APPLICATION  "B"  ENHANCED  (ABE) 

Material  receiving  within  UADPS-SP  falls  under  the 
physical  distribution  functional  area.  The  receiving 
portion  of  physical  distribution  is  guided  by  a  two  cycle 
recording  concept  called  "controlled  post."  This  concept 
requires  in  cycle  number  1,  the  "in-process"  cycle,  that 
receipt  of  material  at  an  activity  be  recorded  in  an  In- 
Process  field  of  a  mechanized  Master  Stock  Item  Record 
(MSIR)  and  can  even  be  reported  as  received  to  the 
applicable  Inventory  Manager.  However,  this  initial  receipt 
cycle  does  not  increase  the  on-hand  balance  of  the  activity 
record.  The  receipt  is  then  tracked  through  cycle  number  2, 
the  "stow"  cycle,  which  concludes  with  physical  storage  and 
generation  of  a  transaction  that  updates  the  MSIR  on-hand 
quantity,  after  positive  confirmation  of 
stowage . 


Application  B  is  the  UADPS-SP  receipt  processing 


application.  Included  within  this  application  are  programs 
which  perform  the  following  functions  [Ref.  38]: 

1.  establish,  maintain,  modify,  inquire,  and  purge  due 
records  on  the  Receipt  Due  File  (RDF)  to  the  Receipt 
Due  History  File  (RDH),  providing  financial  data 
updates  as  required; 

2.  follow-up  or  cancel  overage  dues; 

3.  record  data  on  the  physical  receipt  of  material  in  the 
RDF  and  the  MSIR,  direct  material  to  the  appropriate 
locations,  notify  Application  C  to  release  issues  held 
in  the  I n-P r oc e s s/ B ac ko rd er  file,  generate  financial 
information  to  applications  E  and  F,  and  generate 
transaction  item  reports  (TIRs)  through  Application  H. 

4.  determine  disposition  of  Material  Turned  into  Stores 
(MTIS),  including  generation  of  transactions  for 
excessing  material  through  Application  M,  taking 
material  into  stock,  or  disposing  of  material,  as 
requ i r ed  . 

5.  generate  management  reports  including  statistical 
reports  on  delinquent  dues,  receipt  processing 
timeframes,  and  performance  of  sources  of  supply. 

Prior  to  October  1982,  all  of  these  functions  were 
performed  at  UADPS-SP  stock  points  primarily  via  Burroughs 
COBOL  programs  on  the  Burroughs  medium  system  mainframes, 
using  remote  card  reader/punch  equipment,  card  inputs  and 
outputs,  and  hard  copy  documents  and  listings.  A  simplified 
example  receipt  transaction  will  help  explain  this  process: 

1.  physical  receipt  of  material  occurs  on  the  receiving 
floor; 

documentation  is  carried  to  some  receipt  control  area 
where  information  is  transcribed  from  the  receipt 
document  to  a  punch  card  for  i  n put / i  n qu i r y  to  the  site 
RDF  via  remote  Burroughs  card  reader/punch  equipment; 


2. 


3.  responses  are  returned  in  card  format,  including  a 
receipt  detail  card,  and  a  stow  card  with  possible 
trailer  information; 

4.  the  receipt  detail  reply  cards  are  matched  to  the 
original  receipt  document  and  input  to  update 
applicable  fields  ( e .  g .  ,  In-process)  on  the  RDF  and 
MSIR;  exceptions  are  returned,  corrected  and  re-input; 

5.  stow  cards  are  attached  to  the  material  while  on  its 
way  to  the  location; 

6.  when  the  material  is  physically  stored,  the  stow  card 
is  re-input  to  update  the  RDF  and  MSIR. 

Similar  processes  are  required  for  receipts  not  from  due, 

contract  receipts,  and  MTIS.  As  may  be  imagined,  this  card- 

oriented  and  paper- i n ten s i v e  process  was  time  consuming, 

error-prone,  and  not  conducive  to  complete  asset  visibility 

nor  management  control  and  oversight. 

For  these  reasons,  receipt  processing  had  been 
identified  as  one  of  the  earliest  potential  benefactors  from 
SPLICE  on-line  processing.  As  such,  NAVSUP  designated  the 
Receipt  Improvement  Program  (RIP)  as  one  of  the  first  and 
foremost  SPLICE  applications. 

The  benefits  to  the  corporation  from  such  a  program 
included  better  asset  visibility;  improved  asset  control; 
reduction  is  inventory  costs  due  to  lost,  erroneously 
processed,  or  stored  receipts;  increased  receiving  clerk 
productivity;  improved  fleet  support  by  having  material 
available  for  issue  faster;  and  elimination  of  obsolete  card 
oriented  hardware.  When  the  delay  in  acquiring  SPLICE 
hardware  occurred,  RIP  was  one  of  the  applications  that 
simply  could  not  wait;  the  payoffs  were  too  great  to  be 


postponed.  The  result  was  the  creation  by  FMSO  of  N  o  n  - 

SPLICE  ABE. 

Non-SPLICE  ABE,  implemented  partially  through  new  and 
revised  c o r e- r e s i d en t  Burroughs  application  programs,  a  new 
Receipt  Control  File  (RCF),  and  using  Burroughs  terminal 
c o nc en t r a t o r s  and  terminals,  eliminated  much  of  the  card 
processing.  This  was  accomplished  by  segmenting  and 
modernizing  the  user  interface  portions  of  the  receipt 
process,  as  well  as  providing  a  NISTARS  interface. 
Specifically,  FMSO  provided  the  capability  to  eliminate 
inquiry,  receipt  detail,  stow,  exception,  and  trailer  cards 
from  receipt  processing  and  replace  them  with  CRT  inputs, 
displays,  and  printer  outputs.  A  simplified,  sample  receipt 
within  non-SPLICE  ABE  might  process  as  follows  [Ref.  39]: 

1.  when  material  is  received,  a  CRT  inquiry  is  made  to  a 
Burroughs  resident  file  to  determine  the  status  of 
this  material  (e.g.,  is  it  on  order,  recorded  as  such, 
etc.).  This  inquiry  results  in  the  computer 
assignment  of  a  5  position  Receipt  Control  Number 
(RCN)  to  this  transaction  and  the  creation  of  a  new 
receipt  control  record  in  the  Burroughs  resident  RCF 
file,  using  the  RCN  as  the  key.  Both  the  Burroughs 
MSIR  and  RDF  files  are  accessed  for  data  and  selectea 
fields  are  brought  to  the  screen  and  transmitted  to 
the  RCF. 

2.  any  exceptions  to  normal  processing  are  output  to  the 
CRT  screen  for  immediate  correction  and  re-entry,  or 
to  a  designated  exception  printer.  Thus,  exceptions 
may  be  worked  prior  to  the  receipt  being  placed  in- 
process  within  Non-SPLICE  ABF  and  exception  visibility 
maintained  anywhere  within  the  receiving  process. 

3.  assuming  the  material  is  on-order,  a  stocked  item,  and 
has  been  pre-assigned  a  warehouse  storage  location,  a 
CRT  display  Receipt  Detail  Transaction  is  output  which 
contains  the  RCN.  Receipt  Detail  transactions  may  be 
further  processed  from  the  CRT  to  begin  "cycle  I." 


These  are  edited  and  validated  prior  to  being 
forwarded  to  normal  receipt  updating  programs.  A  hard 
copy  Material  Movement  Document  (MMD)  is  also  printed 
and  attached  to  the  material  to  assist  in  storage. 

4.  all  follow-up  receipt  actions  for  this  transaction  may 
then  be  taken  and  recorded  via  other  CRT  screens.  The 
Burroughs  RCF  record  is  continually  available  for 
inquiry  or  update  by  adjustment  transactions  to  record 
the  latest  action  against  the  received  material,  as 
well  as  NISTARS  interface  transactions. 

5.  following  completion  of  storage,  one  of  several  CRT 
stow  frames  may  be  used  to  confirm  the  storage  action 
and  initiate  cycle  2  final  update  of  the  Burroughs 
MSIR  and  RDF  files. 

In  addition,  the  implementation  of  Non-SPLICE  ABE  provided 
increased  information  about  the  status  of  the  receiving 
operation:  the  receipt  clerks  could  obtain  individual 
receipt  information  status  at  the  touch  of  a  button  and 
management  received  new  visibility  of  the  entire  site 
receiving  process  via  hardcopy  reports  providing  detailed 
status  of  non-compl eted  receipts  through  the  RCF  file. 

The  implementation  of  Non-SPLICE  ABE  has  been 
successfully  completed  at  many  UADPS-SP  stock  points  to 
date.  Although  successful,  Non-SPLICE  ABE  has  encountered 
pr ob 1 em  s  : 

1.  Burroughs  Host  dependence  -  This  has  resulted  in  two 
probl ems  : 

a.  when  the  Burroughs  is  down,  receiving,  shortly 
thereafter,  stops.  Although  this  can  be  tolerated 
for  short  periods  of  time,  lack  of  receiving  lay- 
down  space  at  many  activities  and  lost  worker 
productivity  during  this  time  will  not  permit  this 
situation  for  long. 

b.  low  response  time  and  high  overhead  processing 

r e qu  i  r em en t s .  To  achieve  an  acceptable  level  of 
terminal  response,  some  Non-SPLICE  ABE  programs 


must  be  made  c o r a~ re s  i  d en t  with  scheduling  ana 
execution  parameters  set  at  time  0/volume  1.  At  a 
high  volume  activity,  this  can  adversely  affect 
other  processing.  Also,  even  with  this  privilegea 
processing  status,  response  times  may  be 
relatively  long. 

2.  lack  of  Burroughs  hardware  availability.  Non-SPLICE 
ABE  requires  additional  Burroughs  hardware  (i.e., 
memory,  some  disk,  and  terminal  concentrators)  that  is 
not  immediately  available  on  NAVSUP  contracts  or  that 
would  only  be  necessary  until  SPLICE.  This  latter 
situation  makes  justification  for  this  hardware  very 
difficult. 

3.  inflexibility  of  management  reports.  Although  the  new 
Non-SPLICE  ABE  management  reports  provided  a  great 
deal  of  new  management  information,  tnere  was  only 
limited  capability  for  management  to  perform  "ad  hoc" 
reporting,  in  user  designated  formats. 

To  resolve  these  lingering  problems,  NAVSUP  directed  that  a 

SPLICE  ABE  be  developed  for  eventual  implementation  by  all 

stock  points  [Ref.  40]. 29 

The  concept  behind  SPLICE  ABE  was  simple:  take  the  best 
from  the  successful  Non-SPLICE  ABE  implementation  and  move 
it  to  SPLICE  TANDEM  hardware  to: 

1.  provide  for  "non-stop"  receiving  for  regular  and 
contract  receipts  by  severing  immediate  receiving 
dependence  from  the  Burroughs  hosts; 

2.  provide  some  capacity  relief  to  the  Burroughs  by 
moving  six  Non-SPLICE  ABE  programs,  the  RCF  (called 
the  RKF  on  SPLICE),  and  the  receiving  terminals  and 
printers  to  SPLICE.  Additional  Burroughs  capacity 
relief  would  also  be  provided  by  directing  MSIR  and 
RDF  read-only  data  requirements  to  the  SPLICE 
Replicated  Files  vice  the  Burroughs  MSIR  and  RDF. 


29jhere  are  currently  three  versions  of  receipt 
processing  in  place:  the  original  card  oriented  version, 
Non-SPLICE  ABE,  and  SPLICE  ABE.  Current  NAVSUP  direction 
appears  to  be  that  the  non-ABE  version  of  receiving  will  not 
be  supported  after  1  June  1987  and  SPLICE  ABE  will  become 
the  only  supported  version  sometime  after  1987. 


3.  further  decrease  receipt  processing  times  by  reducing 
CRT  response  and  document  preparation  times  when  using 
the  more  on-line  and  inquiry  oriented  TANDEM  systems; 

4.  provide  the  user  the  capability  to  generate  non¬ 
standard  or  ad  hoc  reports  via  TANDEM'S  ENFORM 
product,  supplementing  FMSO  provided  management 

r  e  po  r  t  s  . 

5.  permit  the  use  of  secondary  keys  on  SPLICE  resident 
files. 

Complete  information  on  the  SPLICE  ABE  design  is  available 
in  [Ref.  41 ] . 

The  processing  scenario  for  a  regular  receipt  under 
SPLICE  ABE  appears  similar  to  that  described  for  a  No  n- 
SPLICE  ABE  receipt  transaction,  once  the  host  and  file 
substitutions  described  above  are  made  and  the  SPLICE 
HYPERchannel  interface  to  the  Burroughs  is  substituted  for 
the  terminal  concentrator  and  Burroughs  FEP  data 
communications  link.  A  critical  difference  is  that  in 
SPLICE  ABE,  the  receiving  terminals,  the  RCF,  and  the  CRT 
user  interface  process  are  running  "non-stop"  on  the 
SPLICE  TANDEM  hosts,  s e nd i ng / r ec e  i  v i ng  transactions  to/from 
the  Burroughs  to  complete  transactions  and  update  master 
files.  In  the  event  of  Burroughs  failure,  receiving  can 
continue  with  all  transactions  destined  for  the  Burroughs 
queued  up  on  SPLICE  and  awaiting  for  the  Burroughs'  return 
to  an  on-line  status. 

Concerning  the  second  area  of  application  analysis 
stated  in  the  overview  of  this  chapter,  the  SPLICE  ABE 


application  can  be  now  analyzed  in  terms  of  its  need  and 
potential  for  migration  to  the  SPAR  Project.  In  reference 
to  the  need  for  migration  of  the  function,  that  goes  without 
saying,  in  that  receiving  is  and  will  remain  a  primary  stock 
point  function.  However,  the  need  for  the  SPLICE  ABE 
application  itself  being  transitioned  to  SPAR  is  highly 
dependent  on  which  remaining  Burroughs  receiving  programs 
the  SPAR  project  office  and  application  personnel  decide  to 
transition. 

It  is  assumed  that  the  pre-ABE  receiving  programs  will 
not  be  considered  for  SPAR  migration.  If  the  Non-SPLICE  ABE 
and  associated  Burroughs  receiving  programs  are  selected  by 
SPAR  for  transition,  no  SPLICE  ABE  program  migration  will  be 
required,  but  upgrade  to  the  receiving  process  will  be 
required  to  incorporate  enhancements  made  within  SPLICE  ABE. 
On  the  other  hand,  if  the  SPLICE  ABE  and  remaining 
associated  Burroughs  programs  are  selected  by  SPAR  project 
and  application  personnel  for  transition  to  the  new 
hardware,  there  will  be  a  need  to: 

1.  continue  to  provide  a  means  to  have  replicated  files 
on  SPLICE  or,  if  sufficient  processing  power  is 
available  on  the  new  hosts,  directly  obtain  MSIR  and 
RDF  file  information  from  the  transitioned  files  on 
the  new  hardware; 

2.  provide  a  means  at  SPAR  transition  time  for  SPLICE-to- 
SPAR  proc e s s- to- pr oc e s s  and  terminal  transaction 


passing,  and  pass  through  via  the  HYPERchannel  or  some 
other  high-speed  data  c omm un  i  c a t  i  o n s  link. 30 

Therefore,  the  function  must  be  migrated,  while  the  form  in 

which  this  migration  takes  is  open  to  question. 

Concerning  the  area  of  migration  potential  to  SPAR  in 
the  receiving  area,  several  comments  can  be  made.  Tne 
potential  for  migrating  or  transitioning  the  Non-SPLICE  ABE 
programs  would  be  appear  to  be  no  different  than  that 
present  in  tr an s i t  i  on  i  ng  any  resident  Burroughs  on-line 
application.  However,  the  user  interfaces  (e.g.,  terminals, 
printers,  screen  formats,  inputs,  etc.)  will  mostly  likely 
be  significantly  different  and  the  programs  may  require 
backfitting  of  SPLICE  ABE  processing  improvements.  Tnis 
remains  in  the  authors'  opinion  a  feasible  approach. 

Migrating  stock  point  receiving  to  SPAR  with  SPLICE  ABE 
also  appears  feasible  in  that  it  reduces  the  SPAR  transition 
application  workload  by  exactly  the  number  of  programs  and 
files  that  remain  resident  on  SPLICE,  maintains  the  current 
user  interface,  and  facilitates  NISTARS-to-SPAR  interface. 31 
This  approach  does  appear  to  increase  the  environmental 
workload  and  risk  in  SPAR  transition  by  forcing  the  issues 
of  Replicated  Files  and  TRANSRECON  Offload  replacement  or 

^ ® T h i s  second  requirement  exists  exclusive  of  SPLICE  ABE 
if  SPAR  wishes  to  continue  to  use  SPLICE  as  their 
telecommunications  and  terminal  concentration  medium. 

3^This  aspect  will  be  discussed  later. 


interface  earlier  into  the  transition  period.  Tnis  approach 
also  appears  impl  ementabl  e  . 

The  final  area  that  will  be  addressed  is  how  SPLICE  ABE 
tactically  supports  or  can  oe  made  to  better  support  tne 
proposed  SPLICE  objectives,  tnereby  supporting  previously 
presented  corporate  and  project  goals  and  strategies. 

SPLICE  ABE  directly  supports  and/or  is  supported  by  the 
following  proposed  SPLICE  project  objectives:  6,  7,  12,  13, 
19,  28,  29,  32,  33,  34,  35,  41,  43,  and  44. 

There  are  several  r ec omm end  a t i o n s  the  authors  have  for 
possible  enhancements  to  SPLICE  ABE  that  will  enable  it  to 
provide  greater  support  or  benefit  to  the  corporation: 

1.  Investigate  the  implementation  of  a  direct  SPLICE  ABE- 

to-NISTARS  interface. 

a.  This  interface  could  be  used  to  reduce  direct 
Burroughs  to  NISTARS  interdependence  and  thus  help 
insulate  NISTARS  from  SPAR  transition. 

b.  The  interface  could  be  used  in  several  processing 
situations.  First,  when  NISTARS  receives  incoming 
material  first  for  stow  and  material  has  not  been 
processed  by  UADPS  Central  Receiving,  NISTARS 
could  send  SPLICE  ABE  a  transaction  that  would  put 
the  receipt  in-process  within  UADPS.  SPLICE  ABE 
would  then  interface  with  the  other  Application  B 
programs  as  is  done  today.  Similarly,  NISTARS  can 
also  send  clean,  frustrated,  and  discrepant  stow 
transactions  to  SPLICE  ABE  for  recording  and 
further  transmission  to  other  Application  B 
programs/processes.  If  SPLICE  ABE  processes  the 
receipt  first,  the  expectant  stow  transaction  and 
any  sim^ar  transactions  could  also  be  sent  to 
NISTARS  irom  SPLICE  ABE  via  this  link. 

c.  A  second  major  use  of  this  interface  would  De  the 
ability  for  either  SPLICE  or  NISTARS  terminals  to 
access  the  files  of  the  other  system  for  inquiry 
or  possibly  update  purposes.  In  tnis  manner  any 
SPLICE  resident  terminal  user  could  also  be 


afforded  NISTARS  and  ABE  file  access  to  accomplish 
tasks  such  as  researching  inventory  discrepancies 
from  the  SPLICE  TLOD  application. 

2.  Investigate  the  incorporation  of  both  TANDEM  based  bar 
code  reading  and  printing  equipment  into  SPLICE  ABE 
receiving. 

a.  A  bar  code  interface  board  to  which  commercially 
procured  reader  equipment  may  be  attacned  is 
already  an  option  on  TANDEM  6530  terminals.  These 
bar  code  reader  interface  boards  could  be 
immediately  available  using  the  SPLICE  contract 
substitution  clause.  Reader  equipment  would 
require  open  procurement;  however,  the  Logistics 
Applications  of  Automated  Marking  and  Reading 
Symbols  (LOGMARS)  project  may  be  of  assistance 
here . 

b.  Medium  and  heavy  duty  laser  printers,  which  are 
capable  of  printing  bar  code  documents,  are  being 
procured  and  interfaced  to  SPLICE  as  a  part  of  the 
APADE  project.  Similar  or  even  more  heavy  duty 
printers  can  also  be  obtained  and  interfaced. 

c.  Bar  code  readers  on  SPLICE  ABE  terminals  could  be 
used  to  input  document  number,  stock  number,  or 
RCN  information,  as  part  of  the  SPLICE  ABE 
initial32  or  follow-up  inquiry  function.  Remote 
bar  code  printers  from  SPLICE  could  be  used  to 
print  labels  for  material  or  bins,  that  could 
subsequently  be  used  in  inventory  and  issue 
processing.  Also,  document  number,  stock  number, 
and  location  data  could  be  bar  coded  on  MMDs, 
which  would  require  only  re-wanding  after  storage 
to  initiate  the  SPLICE  ABE  storage  transactions. 

3.  Investigate  the  use  of  a  more  direct  interface  between 
SPLICE  ABE,  Application  B,  and  the  under  development 
SPLICE  Defense  Data  Access  (DDA)  System.  Such  an 
interface  could  be  used  to  automatically  input 
transactions  to  Application  B  processes  which 
previously  were  received  via  AUTODIN/OLA,  as  well  as 
forward  on-line  Application  B  external  outputs  to 
ICPs/ I  tern  Managers. 

4.  Investigate  the  downloading  of  program  UA51,  RDF  scan, 
exception,  notification  output,  and  follow-up 

^Assumes  that  incoming  receipts  will  contain  bar  code 
labels  in  the  immediate  future. 


transaction  generation  to  SPLICE  using  Replicated 
Piles.  This  would  provide  additional  capacity  relief 
to  the  Burroughs,  as  well  as  permit  more  timely  ana 
frequent  processing.  Any  RDF  or  MSIR  master  file 
update  actions  that  now  originate  from  this  process 
would  be  sent  to  the  Burroughs  for  master  file 
updating . 

5.  Investigate  the  movement  of  the  entire  B07  Operation, 
Management  Products,  to  SPLICE,  using  the  SPLICE 
resident  and  replicated  files.  Implement,  where 
possible  with  ENFORM. 

6.  Investigate  the  development  of  a  SPLICE  MTIS  external 
user  (i.e.,  for  use  by  ships)  screening  and  tracking 
process  using  REP  FILES.  This  process  should  be 
executable  by  remote  users,  particularly  from  a 
shipboard  DDN  customer,  with  output/ resul  ts  returnable 
to  the  user.  This  process  would  indicate  to  the  user 
which  material  to  bring  to  the  Supply  Center,  where  to 
deliver  it,  indicate  whether  financial  credit  will  be 
given  for  the  return  and  any  special  processing 
instructions,  indicate  which  material  should  be  sent 
directly  to  disposal,  and  begin  a  tracking  cycle  for 
selected  material,  especially  high  value  turn-ins. 

This  concludes  the  discussion  of  SPLICE  ABE.  The 
second  SPLICE  physical  distribution  application,  the  NAVADS 
project  will  be  addressed  next. 33 


C.  NAVY  AUTOMATED  TRANSPORTATION  DOCUMENTATION  SYSTEM 
(NAVADS) 

NAVADS,  like  ABE,  is  a  central  player  in  the  physical 
distribution  function  at  the  NAVS'JP  stock  points.  Also  like 
ABE,  it  was  one  of  the  original  SPLICE  designated 
applications  that  required  immediate  development  and 
deployment  when  the  SPLICE  project  was  delayed  in  1979. 


3  3 1 1  had  been  the  authors'  intention  to  discuss  the 
SPLICE  initiatives  in  the  "G"  Condition  Depot  Level 
Repairables  area.  Requested  documentation  on  this 
application  was  not  received. 


The  NAVADS  system  provides  stock  points  with  automatea: 

1.  basic  shipment  related  aata  for  use  in  otner  modules; 

2.  management  control  of  their  shipping  function  and 
snipment  consolidation  recommendations; 

3.  shipment  documentation  preparation,  including  proof  of 

sh i pment . 34 

The  first  two  subsystems  are  Burroughs  resident  and  are 
planned  to  remain  so.  It  is  the  third  subsystem,  Subsystem 
III  or  the  Automated  Documentation  Subsystem,  that  is 
designated  for  SPLICE  transition  from  its  current  PE  3200 
series  hardware  implementation,  using  the  OSMT/32  operating 
system  and  utilities,  the  FMSG  INS  data  communications 
software,  and  the  TAPS  software. 

NAVADS  Subsystem  III,  which  will  be  referred  to  as 
simply  NAVADS  hereafter,  is  a  very  large  application 
consisting  of  about  130  interactive  and  batch  programs.  For 
specific  processing  information,  readers  are  directed  to 
[Refs.  42  and  43],  A  general  overview  of  processing 
capabilities  will  be  presented  here  to  assist  tne  reader  in 
understanding  this  complex  and  heavily  interfaced 
appl ication. 

Processing  within  NAVADS  begins  with  the  receipt  by  the 
PE  system  of  requisition  and  shipment  unit  information  from 
the  Burroughs  resident  Subsystem  II.  This  information  may 
either  be  passed  via  a  telecommunications  line  or  in  batches 

^References  to  transhipment  and  local  delivery  modules 
have  been  observed  but  no  specific  information  on  these 
impacting  SPLICE  was  received  from  FMSO. 


via  tape  from  the  Burroughs  host.  Received  information  is 
posted  in  up  to  three  NAVADS  PE  TAPS  files:  the  Requisition 
Data  File,  the  Shipment  Unit  Data  File,  and  the  Hazardous 
Requisition  Oata  file,  if  required.  Once  established  in 
these  files,  the  NAVADS  system  maintains  positive  control 
and  provides  a  tracking  capability  against  both  material  and 
shipments  until  all  shipment  and  proof  of  shipment  actions 
required  have  been  completed. 

Once  shipment  data  is  loaded,  NAVADS  users  may  apply: 
inquiries  as  to  workload  status;  packing  floor  and  shipping 
updates;  input  tracking  or  shipping  modification  information 
to  the  requisition  and  shipment  unit  Shipment  Control 
Numbers  loaded  from  Subsystem  II  and/or  to  the 
tr an s por ta t i on  unit  Shipment  Control  Numbers  assigned;  and 
produce  local  hardcopy  listings  to  assist  in  work  scheduling 
or  job  staging.  These  inputs  are  primarily  CRT  originated, 
using  Burroughs  compatible  devices,  with  outputs  both  CRT 
and  remote  printer  destined. 

While  a  shipment/transportation  unit  is  passing  through 
all  required  preparation  and  handling,  shipping 
documentation  is  prepared  on-line  and  printed  at  remote 
printers  in  the  shipping  area.  Shipping  documentation 
includes  Government  Bills  of  Lading,  Commercial  Bills  of 
Lading,  Military  Shipment  Labels  (DD  1387-4),  Transportation 
and  Movement  Documents  (DO  1384),  and  Notices  of 
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Availability  (DD  1348-5).  These  various  documents  are 
affixed  to  shipping  containers  as  required. 

NAVADS  completes  its  processing  by  preparing  proof  of 
shipment  documents  which  can  be  forwarded  back  to  the 
Burroughs  hosts  either  on-line  through  telecommunications 
lines  or  via  batch  tape  updates.  It  also  prepares 
transaction  images  which  are  destined  for  A U T 0 D I N  I 
transmission  (e.g..  Notices  of  Availability,  Transportation 
Control  and  Movement  Documents,  etc.). 

NAVADS  has  a  direct  NISTARS  TANDEM  Non-Stop  II  interface 
role.  This  interface  is  physically  accomplished  via  another 
telecommunications  line  and  through  tape  passing.  Interface 
transactions  between  NAVADS  and  NISTARS  include  cancellation 
processing;  piece,  weight,  cube  updates;  issue  adjustment 
transactions;  split  shipment  unit  transactions;  shipment 
mode  changes;  Parcel  Post/United  Parcel  Service  (UPS)  Proof 
of  Shipment. 

Finally,  NAVADS  provides  management  a  whole  series  of 
reports  to  assist  in  keeping  tabs  on  the  response  time 
critical  shipping  operation.  These  include:  On-Line  Local 
Oelivery  Report,  Batch  Shipment  H i story/ Report ,  Overaged 
Local  Delivery  Report,  Overaged  Parcel  Post/UPS  Requisition 
Report,  Outstanding  Transshipment  Report,  Requisition  Late 
to  Packing  Report,  and  the  Batch  Tonnage  Distribution 
Re  por  t ,  to  name  a  few . 
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The  transition  strategy  from  PE  NAVADS  to  SPLICE  NAVADS 
is  to  keep  the  transition  as  transparent  as  possible  to  the 
application  by  porting  TAPS,  in  its  updated  TAPS  II  PASCAL 
form,  to  the  SPLICE  TANDEM  system.  Now  tnat  TAPS  II  is 
available  on  SPLICE,  current  screens  will  be  reimplemented 
in  TAPS  II,  files  moved  to  TANDEM  ENSCRIBE  format  and 
interfaced  to  TAPS  II,  programs  re-compiled  into  TANDEM 
COBOL  and  interfaced  to  TAPS  II,  and  terminal  device  and 
security  functions  placed  under  the  control  of  the  FDC's 
SAS/TMAP  processes.  Without  processing  efficiency 
enhancements,  TAPS  II  on  TANDEM  is  not  a  usable  product  in 
an  operational  environment.  These  enhancements  are  being 
undertaken.  The  alternative  method  to  get  NAVADS  to  SPLICE 
would  required  a  complete  re-design  by  FMSO  of  the  current 
system  into  the  TANDEM  native  mode  TPS  using  PATHWAY  and 
ENCOMPASS,  prior  to  any  usage  on  SPLICE.  Economic 
justification  of  this  alternative  would  be  difficult  and 
would  require  continued  PE  TAPS  support  during  the  duration. 

The  benefits  to  the  corporation  from  NAVADS  are 
documented  in  [Ref.  42]  and  include:  optimization  of 
shipping  personnel  resources,  positive  control  of  and 
reporting  on  the  status  of  the  pac k i ng / s h i p p  i  ng  process  at  a 
site,  workload  planning  and  staging  tools,  automated 
preparation  of  labels  and  forms  required  for  shipping, 
automatic  proof  of  shipment  passed  to  UADPS-SP,  and  an 
automated  NISTARS  interface.  However,  these  benefits  exist 


regardless  of  any  SPLICE  initiatives.  Transition  of  NAVAOS 
to  SPLICE  additionally  will  provide  the  corporation  four 
things:  a  reduction  in  non-SPLICE  minicomputer  system 
support;  non-stop  shipping  support;  a  reserve,  expansion, 
and  growth  capability  for  NAVAQS;  and  the  potential  for 
developing  an  integrated  physical  distribution  function. 

The  transition  of  NAVAOS  to  SPLICE  eliminates  the  need 
for  approximately  one  half  of  the  PE  minicomputers  in  the 
NAVSUP  inventory;  the  other  half  being  used  on  FMSO  IDA. 

This  helps  achieve  one  of  the  original  SPLICE  objectives:  tc 
standardize  stock  point  minicomputers.  This  also  reduces 
the  need  for  vendor  software  support  for  NAVSUP  PE  systems 
as  well  as  FMSO  support  for  multiple  versions  of  TAPS  and 
current  FMSO  developed  and  maintained  INS  software. 

Software  lease  and  maintenance  as  well  as  personnel  savings 
can  accrue  to  the  corporation  from  this.  As  a  longer  term 
benefit,  the  number  of  different  minicomputers  which  SPAR 
must  interface  to,  and  later  absorb,  will  be  reduced. 

NAVADS  on  PE  has  periodically  suffered  from  both 
hardware  and  software  problems  that  have  brought  the  system 
to  its  knees  and  subsequently  backlogged  the  NAVADS  shipping 
documentation  efforts.  In  a  single  processor,  no n-m  i  r ro r ed 
disk,  and  single  host  resource  environment,  such  as  is 
present  in  the  PE  system',  this  will  always  be  a  potential 
problem.  Since  SPLICE  has  no  single  point  of  failure, 
employs  mirrored  disks  to  protect  data,  and  has  facilities 


for  sharing  peripheral  resources,  system  uptime  and 
availability  should  be  significantly  improved  when  NAVADS 
moves  to  SPLICE. 

The  PE  implementation  of  NAVADS  had  also  experienced  a 
capacity  problem  from  its  inception  at  its  prototype  site, 
NSC  Oakland.  This  was  evidenced  by  what  was  termed  "the 
systems'  inability  to  complete  a  day's  worth  of  business 
within  24  hours."  After  numerous  FMSQ  system  tunings  and 
program  efficiency  modifications,  the  immediate  problems 
were  resolved,  but  the  long  term  specter  of  no  growth,  nor 
surge,  and  limited  expansion  capability  has  remained  with 
the  application.  Additionally,  the  source  for  large  enough 
PEs  for  follow-on  sites  has  remained  a  question.  SPLICE  on 
TANDEM,  with  its  available  host  capacity  (i.e.,  1,040  4MB 
memory  processors)  and  modular  expansion  capability, 
requiring  no  application  changes  to  accommodate  growth,  can 
provide  the  solution  to  this  problem. 

Lastly,  in  the  interim  to  SPAR,  SPLICE  holds  the  key  to 
integrating  the  non-Burroughs  portions  of  the  physical 
distribution  system.  With  SPLICE  ABE  and  NAVADS  on  TANDEM 
TXP  hosts,  NISTARS  on  TANDEM  Non-Stop  II  hosts,  and  the 
ability  of  TANDEMs  to  logically  function  as  a  single  system 
using  o f f - t he- s h el f  software,  the  potential  for  integrating 
or  eliminating  transactions,  files,  and  non-TANDEM 
interfaces  among  these  systems  is  very  large.  This  will 
depend  on  FMSO's  ability  to  assume  the  NISTARS  system  from 


contractor  support  and  being  funded  to  perform  the  needed 
integration  actions . 

Assuming  the  transition  of  NAVADS  to  SPLICE,  there  is  no 
need  for  migration  of  NAVADS  to  the  SPAR  transition 
environment.  The  SPLICE  terminal  and  proc ess- to- proc ess 
interfaces  to  SPAR  will,  however,  also  be  required  here. 

When  SPLICE  is  replaced  by  modernized  SPAR,  the  SPLICE 
resident  functions  of  NAVADS  will  require  migration,  but  not 
the  current  processes.  Elimination  of  SPLICE  NAVADS  will 
require  both  redesign  and  development  on  the  new  system. 

Once  NAVADS  transitions  to  SPLICE,  it  will  tactically 
support  or  can  be  made  to  better  support  the  following 
proposed  SPLICE  objectives,  thereby  supporting  previously 
presented  corporate  and  project  goals  and  strategies:  6,  7, 
8,  12,  13,  14,  15,  18,  19,  29,  32,  35,  41,  47. 

The  authors  have  several  recommendations  for  possible 
enhancements  to  NAVADS,  when  transitioned  to  SPLICE,  that 
will  enable  it  to  provide  greater  support  or  benefit  to  the 
corporation.  These  are: 

1.  Investigate  the  integration  potential  for  NAVADS  and 
NISTARS  files,  transactions,  and  interfaces. 
Particularly,  investigate  the  use  of  NISTARS 
transactions  to  update  NAVADS  files  directly  and  vice 
versa  and  the  substitution  of  new  common  files  instead 
of  separate  files  containing  redundant  data. 

2.  Investigate  the  interface  of  NAVADS  to  DDA  in  order  to 
pass  AUTODIN  I  destined  transactions  directly  into  the 
system. 

3.  When  economically  justified,  replace  the  less 
functionally  capable  Burroughs  terminals  with  either 
TANDEM  or  IBM  3270  series  compatible  terminals. 


4. 


Investigate  the  distribution  of  NAVADS  management 
reports  to  local  management  via  TANDEM  TRANSFER  or 
PS/Mail,  thus  reducing  hardcopy  and  paper  output 
requirements. 

5.  Investigate  the  use  of  the  TANDEM  T-Text  Word 
Processing  capability  to  replace  COBOL  programs 
currently  generating  transportation  documents,  similar 
to  that  which  is  being  done  in  APADE. 

6.  Develop  a  plan  to  transition  the  NAVADS  application 
off  TAPS  II  entirely  to  native  mode  TANDEM 

PATHWAY / ENCOMPASS .  During  PE  to  SPLICE  transition  of 
Subsystem  III,  convert  batch  programs  to  TANDEM  native 
TPS  mode,  where  economically  feasible. 35 

7.  If  additional  Burroughs  capacity  relief  or  downloads 
are  desirable,  investigate  the  download  of  both  NAVADS 
Subsystems  I  and  II  to  SPLICE.  There  appears  nothing 
in  either  subsystem  which  mandates  their  processing  on 
the  Burroughs.  If  accomplished,  this  would  return 
capacity  to  the  Burroughs,  reduce  SPAR  transition 
requirements,  permit  NAVADS  to  be  implemented  at  any 
stock  point  where  SPLICE  is  planned,  and  more  closely 
integrate  and  collocate  physical  distribution 
functions  on  the  TANDEM  systems. 

With  these  recommendations  completed,  the  NISTARS 
application  will  next  be  addressed. 


D.  NAVAL  INTEGRATED  STORAGE,  TRACKING,  AND  RETRIEVAL  SYSTEM 
(NISTARS) 

NISTARS  is  not,  nor  has  it  ever  been,  a  SPLICE 
application.  It  is  not  SPLICE  targeted  and  is  still  today  a 
contractor  maintained  system.  It  is  being  included  under 


35jhe  authors  are  assuming  that  the  original  TAPS  II 
conversion  specifications,  which  called  for  the  interface 
and  use  of  ENSCRIBE  files  instead  of  TAPS/DM  VISAM  files, 
was  executed.  If  so,  standard  PATHWAY  or  TANDEM  COBOL 
programs  should  be  able  to  process  against  these  files 
concurrently  with  TAPS/AM  applications.  The  specification 
was  so  worded  to  enable  a  phased  transition  from  TAPS  II  to 
TANDEM  native  mode  processing. 


this  section  on  centrally  designed  SPLICE  applications 
because  the  authors  feel  that  the  future  deployment  of 
certain  NISTARS  concepts  and  programs  on  SPLICE  can  assist 
the  corporation  in  accomplishing  one  of  its  primary 
missions:  maintenance  of  accurate  physical  inventories  and 
inventory  records  in  the  logistics  system. 

NISTARS  is  NAVSUP's  flagship  integrated  physical 
distribution  system. 36  when  fully  implemented,  NISTARS  wil 
be  able  to  automatically  or  with  minimal  user  input  control 
inventory  of  parts  and  material;  receipt  processing 
including  assignment  of  storage  area;  storage,  tracking  and 
retrieval  of  material  for  issue;  consolidation  of  orders; 
and  printing  of  shipment  documents.  The  system  is 
considered  a  "closed  loop  system."  That  is,  it  accepts 
known  inputs  from  external  sources,  performs  predefined 
functions  based  upon  the  content  of  the  input,  and  reports 
the  results  of  its  action  back  to  input  source.  The  end 
results  or  benefits  to  NAVSUP  of  these  activities  are 
greater  consistency  in  management  and  control  of  existing 
and/or  expanded  high  demand  parts  inventories  with  fewer 
personnel,  in  a  shorter  time,  and  with  greater  accuracy. 

Although  these  benefits  were  originally  expected  to 
accrue  to  only  the  NISTARS  mechanized  areas  where  high 
volume,  fast  moving  items  would  be  placed,  with  the 

3  6 1 1  is  also  probably  the  most  audited  due  to  its 
implementation  slippage  and  cost  increases. 


puolicizing  of  the  NAVSUP  inventory  accuracy  proolems  in  the 
early  1980s  a  re-evaluation  of  this  concept  was  undertaken 
[Ref.  44].  High  volume  items  represent  a  low  percentage  of 
the  inventory  cost  of  the  supply  system;  to  get  real  control 
of  inventory  accuracy,  NISTARS  control  needed  to  be  extended 
to  no n-m ec han i zed  warehouses.  The  NISTARS  project  was  aole 
to  accommodate  this  change  of  direction  for  planned  sites  by 
program  changes  and  procuring  an  increased  number  of  the 
NISTARS  intelligent  workstations. 

NISTARS  was  originally  designed  and  designated  as  an 
"embedded"  vice  general  purpose  ADP  system:  85%  of  the 
system  is  considered  process  control  and  15%  interface 
oriented.  This  designation  had  been  challenged  by  GAO  in 
1979,  but  the  Navy  did  not  concur  with  the  finding.  It 
maintained  that  NISTARS  is  a  process  control  computer 
embedded  in  an  automated  material  handling  system  ( AM H S ) 
and,  as  such,  should  not  be  procured  under  the  Brooks  Act 
(PL  89-306)  as  would  any  other  general  purpose  ADP  system. 
The  NISTARS  "embedded"  system  designation  was  useful  at  the 
time  of  initial  system  procurement  since  it  eliminated 
several  review  and  approval  steps. 

The  total  NISTARS  "embedded"  system  consists  of  various 
automated  material  handling  equipment  components  (e.g.,  tote 
boxes,  manned  storage  retrieval  machines,  m i n i s t ac k er s  , 
binable  manual  storage  retrieval  machines,  conveyors, 
sorters,  consolidation  carousels,  etc.),  TANDEM  Non-Stop  II 


host  processing  systems,  intelligent  workstations  for  user 
interface,  and  software  modules  that  perform:  interface, 
issue,  receipt,  tracking,  warehouse  planning,  storage 
location  management,  performance  reporting,  and  management 
reporting.  The  N I  STARS  processing  activities  are  driven  by 
other  data  processes  within  mainline  UADPS-SP,  Non-SPLICE 
ABE,  and  PE  NAVADS,  by  means  of  both  on-line  data 
communications  and  batch  tape  inputs. 

A  detailed  discussion  of  planned  NISTARS  functions  is 
available  in  [Ref.  45]  and  interface  requirements 
specifications  in  [Ref.  46].  Due  to  the  large  number  of 
functions  and  transactions  performed  by  NISTARS  and  limited 
documentation  held  by  the  authors,  no  attempt  will  be  made 
to  provide  sample  NISTARS  transactions  or  processing 
scenarios. 

Currently,  NISTARS  is  implemented  at  NSC  Oakland  and 
planned  for  NSCs  San  Diego,  Norfolk,  and  Jacksonville.  No 
definitive  plans  for  NISTARS  implementation  or  commercial 
automated  material  handling  system  alternatives  for  the 
other  stock  point  hosts  or  satellite  sites  were  uncovered 
during  this  research. 

If  no  changes  to  current  plans  are  made,  NISTARS  must  be 
interfaced  to  the  SPAR  transition  environment,  both 
physically  and  pr og r amm a t i c a  1 1 y .  This  will,  at  a  minimum, 
require  changes  within  the  NISTARS  interface  module  (e.g., 
no  Burroughs  telecommunications  to  support).  At  some  point 


during  SPAR  mod er n i z a t  i  o n ,  NISTARS  functionality  must  be 
subsumed  by  SPAR,  as  the  current  NISTARS  hardware  approaches 
obsolescence.  If  the  recommendations  which  follow  are 
adopted,  NISTARS  will  be  shielded  from  SPAR  transition  by 
SPLICE,  but  will  still  require  replacement  by  the  post- 
SPLICE  modernized  SPAR  system. 

Before  any  recommendations  in  this  area  can  be  made,  it 
should  be  noted  that  a  '‘political"  roadblock  stands  between 
NISTARS  and  SPLICE  integration.  SPLICE  is  designated  as 
supporting  general  purpose  ADP  system  applications,  most  of 
which  require  LCM  approval  independent  of  SPLICE  itself. 

This  difference  in  designation  between  NISTARS  (embedded) 
and  SPLICE  (general  purpose)  can  preclude  the  NISTARS-SPLICE 
interface  recommendations  already  discussed  within  the 
SPLICE  ABE  and  NAVAOS  application  sections  above,  at  least 
from  the  NISTARS  side,  and  those  recommendations  to  be 
presented  below.  Although  this  difference  in  system 
designation  may  be  a  problem,  it  is  considered  a  political 
one,  not  an  ADP  one.  The  authors  will  advocate  several 
additional  technically  feasible  interfaces  between  the 
NISTARS  and  SPLICE  projects  that  are  in  accordance  with  the 
c  o  r  po  r  a  t  i  o  n  '  s  information  system  plan.  The  political 


"initiatives"  to  implement  the  recommendations  are  left  for 
others  to  masterm  ind  .  37 

The  authors  propose  the  following  additional  actions  in 
the  area  of  N I  STARS- SPL I CE  integration  be  pursued,  following 
government  acceptance  and  support  of  NISTARS: 

1.  Hove  the  Navy  Systems/NISTARS  Interface  function  to 
SPLICE. 

a.  This  relieves  the  Burroughs  of  the  NISTARS  data 
communications  interface  requirement;  accomplishes 
a  NAVSUP  Strategic  Information  System  Plan 
objective  of  removing  telecommunications  devices 
off  the  Burroughs  FEPs;  and  physically  insulates 
NISTARS  from  SPAR  transition. 

b.  All  TANDEMs  within  a  stock  point  can  be  interfaced 
to  the  Burroughs  solely  through  the  SPLICE 
HYPERchannel  connection.  N I  ST A RS- to- SP L I C E 
interface  can  be  accomplished  via  TANDEM 
EXPAND/FOX  or  high  speed  TANDEM  E XP AND / D i r ec t 
Connect  links.  This  would  eliminate  the  support 
requirement  for  the  Burroughs  Tributary  Monitor,  a 
non-standard  TAND EM- to- B ur r oug h s 
telecommunications  software  package  in  NISTARS. 

c.  The  functional  movement  of  the  NISTARS  interface 
function,  validation,  and  edit  routines  to  SPLICE 
returns  some  capacity  to  the  NISTARS  systems  which 
can  be  used  for  other  NISTARS  initiatives. 

2.  Provide  for  all  future  NISTARS  TANDEM  capacity 
enhancements  and  future  maintenance  via  the  SPLICE 
contract. 

a.  The  SPLICE  available  TANDEM  technology  is  more 
current  and  the  pr ice/ per formance  ratios  and 


37it  may  be  useful  to  note  that  NAVSUP  has  a  blanket 
approval  from  NAVD AC/ NAVMAT  to  "download"  functionally 
equivalent  or  "change  of  media"  UADPS-SP  processes  to 
SPLICE.  Once  NISTARS  becomes  an  accepted  UADPS-SP 
application,  it  could  be  argued  that  the  no n-mec ha n  i  z ed 
warehouse  portions  of  NISTARS,  exclusive  of  the  AMHS 
processes  and  hardware,  may  be  functionally  transitioned  to 
SPLICE  replacing  existing  manual/card  processes,  via  mere 
notification  in  follow-on  SPLICE  SDP  document  submissions. 


volume  discounts  are  much  higher  than  that 
obtainable  from  Sperry. 

b.  Monetary  savings  can  accrue  to  the  government  by 
having  a  single  maintenance  contract  (e.g.,  spares 
support,  start-up  costs,  etc.)  for  all  TANDEM 
hardware  at  a  single  NAVSUP  stock  point.  Tne 
NISTARS  hardware,  once  government  owned,  can  be 
covered  by  the  SPLICE  maintenance  contract, 
instead  of  a  separate  contract  to  Sperry. 

c.  In  a  related  vein,  consideration  should  be  given 
to  replacing  all  the  NISTARS  processors  with 
SPLICE  Non-Stop  TXPs  and  re-deploying  the  Non-Stop 
1 1 s  to  future  SPLICE  MAPS  sites.  Most  MAPS  sites 
do  not  appear  to  require  the  full  TXP  minimum 
configuration  to  perform  their  mission.  NISTARS 
priority,  foot  print  requ i r ements ,  backup 

requ  irements ,  and  need  for  commonalty  with  SPLICE 
hardware  at  a  host  site  would  justify  this  step. 

Upgrade  all  NISTARS  environmental  software  to  current 

SPLICE  levels  and  maintain,  in  support  of  the 

following: 

a.  Current  NISTARS  non-standard  recovery  methods 
should  be  upgraded  to  off-the-shelf  Transaction 
Monitoring  Facility  procedures,  with  additional 
capacity  required  provided  by  SPLICE. 

b.  Current  NISTARS  application  routines  written  in 
TANDEM  Transaction  Application  Language  (TAL) 
(equivalent  to  assembler  language)  should  be 
identified,  isolated,  and  transitioned  to  TANDEM 
COBOL  or  FORTRAN,  with  SPLICE  providing  any  needtu 
additional  capacity.  This  will  make  these 
routines  more  maintainable  by  the  government  and 
portable.  If  this  is  not  possible,  task 
maintenance  of  these  routines  to  FDC  as  part  of 
on-site  FMSO  support. 

c.  The  NISTARS  applications  written  in  the  pre- 
PATHWAY  TPS  should  be  upgraded  to  PATHWAY.  This 
means  less  development  software  to  have  to  train 
for,  maintain,  and  distribute,  as  well  as  having  a 
single  TPS  which  is  supported  by  TANDEM  corporate. 

d.  NISTARS  applications  should  be  interfaced  to  the 
SPLICE  Security  Access  System.  This  provides  a 
secure  mechanism  for  other  SPLICE  application 
systems  to  interface  to  NISTARS  and  provides  a 


single  security  system  for  all  stock  point  TANDEM 
appl ications. 

e.  When  all  NISTARS  software  is  at  SPLICE  release 
levels,  future  FMSO  release,  maintenance,  and 
testing  of  TANDEM  off-the-shelf  software  will  be 
greatly  facil itated. 

4.  Investigate  the  augmentation  or  replacement  (when 
required)  of  the  $30,000  Sperry  Intelligent  Remote 
Terminals  (IRTs)  with  I3M  compatible  Personal 
Computers  (PCs)  or  TANDEM  DYNAMITE  workstations, 
configured  with  bar  code  readers,  printers,  magnetic 
badge  readers,  etc.,  to  perform  required  functions. 

5.  Isolate  NISTARS  no n -m ec ha n  i  z ed  warehouse  processing 
applications  in  each  NISTARS  functional  area, 
repackage,  and  export  as  a  Mini-NISTARS  application  to 
all  non-NISTARS  stock  points  using  SPLICE.  This  will 
assist  the  "system"  in  inventory  accuracy.  If  in  fact 
no n-mec han i z ed  NISTARS  warehouse  control  at  current 
NISTARS  sites  does  assist  in  inventory  accuracy, 
exportation  to  all  SPLICE  host  sites  should  also  be 
justified  and  "self-financing"  in  terms  of  monetary 
saving  from  improved  inventory  accuracy.  Use  results 
of  recommendation  4  above  for  non-mec han i zed  IRTs. 

6.  Refer  to  recommendations  in  SPLICE  ABE  and  NAVADS 
areas  for  further  functional  area  integration  efforts. 

The  result  of  this  N I  STARS- SPL I C E  marriage  will  be 
tactical  support  for  the  following  proposed  SPLICE  project 
objectives:  6,  7,  8,  9,  11,  12,  19,  28,  29,  32,  33,  38,  41, 
and  48 . 

This  concludes  the  discussion  on  NISTARS-SPLICE 
"merger."  The  SPLICE  REP  FILES  and  TRANSRECON  Offload 
initiatives  will  be  addressed  next. 


E.  REPLICATED  FILES  (REP  FILES)  AND  TRANSACTION 
RECONSTRUCTION  (TRANSRECON)  OFFLOAD 

REP  FILES  and  TRANSRECON  Offload  are  not,  strictly 

speaking,  " a pp 1  i c a t i o n s . "  They  are  env  i  ro nmen ta 1  mechanisms 


from  which  application  rich  off-snoot  areas  have  emerged: 
the  SPLICE  Information  Center  and  Application  "P"  Inquiry 
System.  In  that  these  processes  are  so  interrelated,  they 
will  be  addressed  within  a  single  area. 

The  nistory  of  REP  FILES  and  TRANSRECON  Offload  is  not 
long  in  terms  of  years;  they  have  only  existed  since  1983. 
The  first  to  evolve  conceptually  was  REP  FILES,  with 
TRANSRECON  Offload  developed  as  the  means  to  implement  it. 

During  the  1982-1983  timeframe,  NAVSUP,  NAVDAC,  FMSO, 
selected  stock  point  representatives ,  and  the  Federal 
Simulation  Center  were  addressing  the  interim  stock  point 
capacity  issue,  with  a  direct  tasking  to  come  up  with  firm 
recommendations  to  ensure  that  sufficient  usable  capacity 
would  be  available  to  get  the  stock  points  through  the  1980s 
or  until  SPAR  could  provide  the  final  solution.  The  problem 
was  multifaceted.  SPAR  was  too  far  away.  SPLICE  promised 
capacity  but  few  applications  to  use  it.  Burroughs  was 
wavering  on  producing  more  B4800s  and  hinting  at  a  new 
B4900.  Faced  with  such  a  tasking,  the  various  factions 
present  brought  in  their  hired  consultants  to  provide 
corroboration  to  their  versions  of  "what  should  be  done." 

Besides  those  contractors  which  studied  the  issue  and 
simply  recommended  replacing  the  whole  UADPS-SP  system 
immediately  or  advocated  sole  source  procurement  of  large 
Burroughs  hosts  as  solutions,  one  proposal  suggested  a  usage 
of  the  IBM  Information  Center  concept.  Specifically,  it  was 


proposed  that  either  tape  extracts  or  periodic  electronic 
images  of  Burroughs  data  files  be  loaded  in  another  format 
(e.g.,  a  DBMS  or  data  manager)  on  an  IBM  or  plug  compatible 
host,  and,  then,  subsequent  redesign  of  selected 
applications  be  undertaken  to  use  this  data  there  instead  of 
processing  on  the  Burroughs.  Among  the  applications 
suggested  for  use  in  what  was  termed  an  "information  center" 
were  terminal  and  batch  inquiry  processing,  the  UADPS-SP 
effort  to  provide  users  ad  hoc  reporting  (UH30  SUPERSCAN), 
and  End-of-Day  processing. 

The  idea  had  merit  but  was  discarded  for  several 
reasons.  Without  SPLICE  or  some  similar  effort,  the 
existing  Burroughs  compatible  terminal  base  could  not  be 
used  on  other  systems.  Using  multiple  terminal  types  was 
inadvisable  due  to  procurement  costs  and  space  limitations 
at  the  stock  points.  Regardless  of  the  terminal  issues, 
stock  point  representati ves  indicated  that  unless  the 
replicated  data  was  "simultaneously”  updated  along  with  the 
Burroughs  master,  it  was  not  current  enough  for  their  users 
and  would  not  be  used.  These  problems  eliminated  the  on¬ 
line  inquiry  applications  from  further  consideration.  The 
tape  data  extract  concept  to  move  po st-TRANSRECON  End-of-Day 
processing  was  also  discarded  because  so  much  of  End-of-Day 
processing  required  the  use  of  Burroughs  data  files  and  the 
passing  of  transactions  back  to  other  Burroughs 
applications.  The  stock  point  representatives  also  balked 


at  the  massive  tape  processing  that  would  be  required  to 
implement  this  approach.  Without  these  other  application 
areas,  the  effort  required  just  to  do  batch  inquiries  and 
U H 3 0  SUPERSCANs  on  anotner  host  could  not  be  justified. 

The  interim  capacity  task  group  finally  recommended  that 
a  combination  of  SPLICE  and  84800s  could  handle  the  stock 
point  capacity  problem  until  SPAR.  In  the  interim,  SPLICE 
was  directed  to  come  up  with  applications  that  could  be 
"easily  downloaded"  with  high  payback  to  the  Burroughs  [Ref. 
47].  This  was  accomplished,  but  required  that  SPLICE 
'  plement  the  information  center  concept  discussed  above  to 
do  it,  despite  the  problems  [Ref.  48]. 

The  key  to  implementing  the  SPLICE  Information  Center 
was  to  find  a  mechanism  that  could  forward  images  of 
Burroughs  data  file  updates  to  SPLICE  in  real-time,  while 
minimizing  added  workload  to  the  Burroughs.  In  the  event 
that  workload  would  be  added  to  the  Burroughs,  it  had  to  be 
compensated  for  through  equivalent  environmental  or 
application  workload  removal.  The  problem  was  easily  broken 
into  pieces  for  analysis;  its  implementation  was  not  so 
easi  1  y  accompl  i  shed  . 

The  real  time  passing  of  data  from  the  Burroughs  to 
SPLICE  could  physically  take  place  over  the  HYPERc hannel  ,  in 
a  manner  similar  to  that  planned  for  terminal  traffic. 
Therefore,  this  aspect  added  no  new  workload  to  the 


3urroughs.38  The  initial  load  of  REP  FILES  on  SPLICE  could 
be  done  ft  om  normal  Burroughs  data  file  bac  kup/ r  ecov  ery 
tapes,  therefore,  this  too  added  no  new  workload.  The  Navy 
Burroughs  environmental  mechanism  through  which  recovery 
images  of  data  file  changes  were  captured  on  disk  or  tape 
was  called  SCSP,  and  at  the  time  was  the  only  place  where 
"hooks"  could  be  incorporated  to  capture  data  file  updates 
images  for  SPLICE  " simul taneousl y"39  with  their  update  on 
Burroughs.  However,  SCSP  was  already  believed  by  FMSO 
environmental  personnel  to  be  a  "system"  bottleneck  in  terms 
of  throughput,  therefore,  adding  an  additional  function  to 
SCSP  was  unthinkabl e.  40  Another  approach  was  required  in 
this  area.  This  aside,  the  SPLICE  resident  REP  FILE  and 
TRANSRECON  file  structures  and  update  programs  would  also 
have  to  be  developed,  but  as  a  wholly  SPLICE  resident 
process,  these  would  have  no  impact  on  the  Burroughs. 
Finally,  the  applications  to  be  "downloaded"  would  have  to 
be  developed  on  the  TANDEM,  again  with  no  negative 
processing  impact  on  Burroughs. 

38jhe  changes  required  in  SDCH  to  accommodate  the  SPLICE 
HYPERchannel  transactions  and  the  interface  Burroughs 
process  itself  to  the  HYPERchannel  are  additional  Burroughs 
workloads,  in  their  own  right. 

39SCSP  was  recommended  for  modification  to  perform  this 
function  by  the  FMSO  SPLICE  Project  office.  It  was  felt 
that  changes  here  would  be  most  transparent  to  application 
personnel.  Any  other  approach  would  (and  did)  require 
application  modifications. 

40SCSP  also  has  other  functions  not  specifically  germane 
to  this  discussion  and  which  it  still  performs. 


The  final  solution  to  the  data  record  update  capture 
problem  required  all  Burroughs  application  programs  whicn 
made  disk  I/Os  to  be  recompiled  and  retested  using  several 
new  copy  routines.  The  incorporation  of  the  . e  new  copy 
routines,  tied  to  a  new  Burroughs  environmental  program 
called  SREC,  permitted  the  relocation  of  the  update 
journaling  function  or  TRANSRECON  process  to  be  selectable 
as  to  location.  At  a  non-SPLICE  site,  SREC  would  maintain 
Burroughs  resident  TRANSRECON  files  on  disk  or  tape  for 
master  file  reconstruc tion  purposes  and  End-of-Day 
processing.  At  a  SPLICE  site,  SREC  would  permit  the  passing 
of  the  TRANSRECON  images  to  the  Burroughs  HYPERchannel 
interface  module,  which  was  expected  to  interface  with  a 
Network  System  Corporation  Burroughs  Network  Executive 
(NETEX)  software  product  and  a  FDC  interface  product.  These 
images  would  be  sent  to  SPLICE. 

When  the  Burroughs  NETEX  package  failed  to  be  usable  in 
an  operational  environment,  FMSO  developed  and  implemented 
their  own  HYPERchannel  interface  between  the  TANDEM  and 
Burroughs  (i.e.,  TABU)  systems.  The  following  describes  the 
basic  REP  F I LE / TR ANSRE CON  processes  using  TABU: 

1.  SREC  passes  a  SPLICE  directed  TRANSRECON  record 
through  the  Burroughs  side  of  TABU  and  the 
HYPERchannel  to  the  SPLICE  portion  of  TABU  and  the 
SPLICE  Complex  Manager; 

2.  data  is  posted  as  received  to  a  replicated  data  TANDEM 
entry  sequence  file; 


3.  this  raw  replicated  entry  sequence  file  data  is  read 
and  segregated  into  at  least  one,  and  possibly  up  to 
nine  Burroughs  Activity  Code  files  per  Burroughs  host; 

4.  the  appropriate  SPLICE  replicated  file  is  updated  with 
the  record  image,  if  it  is  a  data  file  update; 

5.  at  close  of  business,  activity  code  segregated 
TRANSRECON  files  are  closed;  TRANSRECON  files  are 
dumped  to  tape  and  forwarded  to  the  Burroughs  for 
f urther  process  i  ng  . 

A  more  detailed  explanation  of  these  processes  in  available 
in  [ Ref .  49 ]  . 

These  SPLICE  replicated  files  are  essentially  exact 
duplicates  of  their  Burroughs  masters  or  at  least  contain 
exactly  the  same  data  as  that  which  would  be  used  to 
reconstruct  the  masters  if  they  were  lost.  The  fils  being 
replicated  to  date  are  the  MSIR,  RDF,  Requisition  Status 
File  (RSF),  and  the  Demand  History  File  (DHF). 

Once  the  replicated  files  were  available'  for  use,  FMSO 
application  personnel  were  able  to  download  and  implement  18 
different  informational  screens  previously  only  available  on 
the  Burroughs  for  SPLICE  terminal  inquiry  use  [Refs.  50  and 
51].  Additionally,  it  was  now  possible  for  significant 
numbers  of  batch  UH30  SUPERSCANS  and  UB54  Batch  Inquiry  runs 
to  be  directed  from  the  Burroughs  to  the  SPLICE  replicated 
files  using  ENFORM  based  inquiries.  Further,  these 
replicated  files  are  available  as  source  data  inputs  to 
other  SPLICE  pr oc e s se s  .  4 1  Concerning  End-of-Day  processing 
using  the  SPLICE  TRANSRECON,  beyond  the  activity  code  split, 

^Examples  are  the  SPLICE  ABE  or  TLOD  applications. 


no  information  was  received  concerning  further  download  to 
SPLICE,  although  a  project  still  exists  to  do  this. 

The  major  benefit  that  REP  FILES  and  TRANSRECON  Offload 
provide  to  the  corporation  is  the  potential  for  freeing  up 
Burroughs  capacity.  This  capacity  can  be  used  by  stock 
points  for  other  business,  as  a  reserve  for  new  or  enhanced 
future  FMSO  Burroughs  applications,  or  as  a  survival  tool 
usable  while  awaiting  SPAR.  Several  less  major  benefits 
also  accrue:  decreased  response  times  for  terminal  inquiries 
using  replicated  files;  less  turn-around  time  for  reports 
directed  against  replicated  files;  a  user  and/or  programmer 
oriented  ad  hoc  report  capability,  not  present  on  the 
Burroughs;  and  the  ability  to  implement  other  SPLICE 
processes  requiring  master  file  source  data  using  the 
repl icated  fil es. 

The  question  of  the  need  and  potential  for  migration  of 
these  processes  to  SPAR  is  a  delicate  one.  First  consider 
need.  It  is  hoped  that  SPAR  receives  sufficient  funding  to 
obtain  all  required  stock  point  site  hardware  and  software, 
as  well  as  funding  and  time  to  perform  the  transition  of  all 
FMSO  and  critical  local  applications  and  interface  these  to 
non-SPAR  resident  required  interfaces  (e.g.,  NISTARS).  If 
so,  SPLICE  could  immediately  give  up  many  of  its  current 
functions  or  applications  and  concentrate  solely  on  SPAR 
telecommunications  issues.  In  light  of  the  current  Gramm- 
Rudman  balanced  budget  initiative  and  the  inability  of  other 


similarly  large  AOP  projects  to  adequately  size  and  budget 
for  all  new  equipment  requirements  on  day  one,  particularly 
user  information  center  and  fourth  generation  language 
driven  requirements,  it  is  questionable  that  sufficient 
funding  will  be  forthcoming. 

The  ability  to  use  SPLICE,  a  sunk  cost,  to  absorb  some 
of  the  stock  point  inquiry  and  report  oriented  workload, 
particularly  during  transition,  should  not  be  discarded  too 
rapidly,  even  though  it  means  continued,  temporary, 
duplicate  data.  Therefore,  it  is  assumed  that  the  need  to 
retain  SPLICE  REP  FILES  and  TRANSRECON  Offload  will  exist  as 
SPAR  transition  funding  becomes  a  target  for  savings. 

The  potential  for  migration  of  these  functions,  which 
should  be  limited  to  the  SPAR  transition  period,  depends  on 
the  corporation' s  willingness  to  develop  and  implement 
environmental  software  that  performs  functions  similar  to 
those  performed  in  the  new  Burroughs  copy  routines,  SREC, 
and  TABU.  If  so,  the  SPLICE  information  center  can  be  re¬ 
established  and  the  SPLICE  TRANSRECON  function  possibly 
serve  as  a  forward/backward  bridge  for  SPAR  transition. 

The  potential  for  migration  is  also  dependent,  however, 
upon  how  the  SPAR  transition  system  data  base  is  planned  and 
what  will  be  done  during  transition  to  applications 
expecting  inputs  currently  obtained  from  the  TRANSRECON.  It 
may  not  be  possible  to  replicate  the  transitioned  data  bases 
if  a  DBMS  is  used  during  transition.  No  references  could  be 


located  on  how  non-recovery  functions  of  the  current 
TRANSRECON  process  would  be  handled  during  SPAR  transition. 
Until  the  SPAR  procurement  proposals  are  available  for 
inspection  and  a  transition  plan  is  documented  in  detail, 
further  comments  in  this  area  are  merely  speculation. 

The  final  area  that  will  be  addressed  is  how  REP  FILES, 
TRANSRECON  Offload,  and  the  SPLICE  Information  Center 
tactically  support  or  can  be  made  to  better  support  the 
proposed  SPLICE  objectives,  thereby  supporting  previously 
presented  corporate  and  project  goals  and  strategies.  These 
initiatives  directly  support  and/or  is  supported  by  the 
following  SPLICE  project  objectives:  6,  7,  8,  10,  11,  12, 

19,  23,  28,  29,  32,  33,  34,  35,  45,  and  46. 

There  are  several  recommendations  the  authors  have  for 
possible  enhancements  in  the  REP  FILES,  TRANSRECON  Offload, 
and  the  SPLICE  Information  Center  areas  that  will  enable  it 
to  provide  greater  support  or  benefit  to  the  corporation: 

1.  Expedite  the  replication  of  (or  in  many  cases,  initial 
disk  load  of)  the  Management  List  -  Navy  (ML-N)  on 
SPLICE  and  provide  update  and  inquiry  programs  to 
support  it.  This  activity  had  previously  been  planned 
for  SPLICE  to  eliminate  programs  C-UB46,  C-UB47,  and 
C-UC91,  as  well  as  a  number  of  local  uniques.  When 
SPLICE  provides  shipboard  access  to  these  files  for 
inquiry,  the  use  of  this  on-line,  accurate  ML-N  would 
be  of  great  assistance  in  ensuring  the  accuracy  of 
requisition  stock  numbers  and  in  pricing  replenishment 
and  not-carried  shipboard  r equ i s i t i o n i ng  actions. 

2.  Request  NAVDAC  to  investigate  the  automation  and 
development  of  a  Master  Cross  Reference  List  ( MCRL ) 
file  and  application  on  SPLICE,  including  both 
updating  and  inquiry  programs.  The  resulting  system 
could  be  implemented  at  NSCs,  NARDACs  and  NARDAFs. 
Direct  shipboard  benefit  could  accrue  from  this 


initiative  in  the  area  of  locally  matching  Federal 
Supply  Code  for  tianufacturer/Part  Number  items  to 
National  Stock  Numbers.  This  would  reduce  both 
procurement  leadtime  and  purchase  activity  workload. 
The  file  could  also  be  of  some  use  to  stock  point 
Technical  Personnel  for  "first  cut"  research  efforts 
on  non-standard  requisitions. 

3.  Investigate  the  incorporation  of  the  full  TRANSRECON 
processing  portion  of  £nd-of-Day  operation  directly 
into  the  SPLICE  Environmental  TRANSRECON  Splitting 
Process.  This  specifically  includes  the  functions 
performed  by  programs  H-UJ96  and  H-UJ97.  The 
functions  performed  by  these  processes  appear  more 
environmental  than  application  oriented  and  could  be 
done  "on-line"  during  the  current  splitting  process. 

4.  Replace  the  current  TRANSRECON  bulk  file  tape  passing 
between  Burroughs  and  SPLICE  with  a  HYPERchannel  on¬ 
line  bulk  file  transfer  capability,  including  direct 
interface  to  applicable  MAPS  scheduling  routines. 

Tape  processing  among  systems  is  error  prone  and 
requires  much  operator  intervention  never  planned  for 
within  SPLICE. 

5.  As  a  longer  term  measure,  r e- i n v e s t i g a te  the 
downloading  of  the  remainder  of  End-of-Day  processing 
and  other  Application  H  report  generation  to  SPLICE. 

a.  Considering  the  reduction  of  tape  handling  this 
would  result  in,  the  potential  reduction  in 
operator  costs,  the  direct  interface  to  DDA  that 
would  be  available  without  operator  intervention, 
the  ability  to  feed  other  SPLICE  on-line  processes 
directly  (i.e.,  TLOD),  and  the  ability  of  SPLICE 
to  absorb  such  transaction  splitting  and 
duplicating  workload  to  return  capacity  to  the 
Burroughs,  the  apparent  delay  in  implementing  (or 
no  plans  to  implement)  these  downloads  should  be 
re-eval  uated  . 

b.  With  End-of-Day  on  SPLICE,  electronic  distribution 
of  the  Application  H  repetitive  reports  (e.g., 
1144,  Semi-annual  Stock  Status  Report,  etc.)  will 
be  possible  through  TRANSFER  client  servers 
locally  and  SPLICENet/DDN  for  long-haul 
distribution.  No  such  capability  exists  on  the 
Burroughs. 

c.  Current  SPAR  Mod er n  i  z a t i o n  Strategy  [Ref.  52] 
calls  for  the  elimination  of  End-of-Day  processing 
in  its  current  form.  Taking  steps  now  to 
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eliminate  the  current  process  from  the  Burroughs 
by  moving  it  to  SPLICE  simply  reduces  the  required 
SPAR  transition  effort  required  later,  when 
resources  will  be  more  strapped  for  time. 

6.  When  SPLICENet  is  fully  functional,  investigate  the 
creation  of  a  user  liorary  of  SPLICE  User  Information 
Center  ENFORM  inquiries,  at  either  F M S 0  or  FDC.  Such 
a  liorary  would  lesson  the  need  for  users  to  "re¬ 
invent  the  wheel"  on  local  inquiries,  functions,  and 
reports  processed  against  replicated  files.  When 
implemented,  library  products  could  be  copied  or  file 
transferred  for  use  at  local  sites. 

7.  Implement  a  stock  point  9  Cog  Asset  Visibility  program 
using  the  SPLICE  REP  FILES  (i.e.,  MSIR).  Both 
individual  site  inquiry  processes  for  determining 
asset  status  and  a  network  oriented  process  which 
would  summarize  all  stock  point  asset  status  could  be 
im pi  em en  ted  . 

This  concludes  this  section  on  REP  FILES  and  TRANSRECON 
processing.  The  Statistical  Location  Survey  application 
will  next  be  addressed. 


F.  STATISTICAL  LOCATION  SURVEY  (STATLOC) 

STATLOC,  previously  called  the  Inventory  Location  Audit 
Project  (I  LAP),  is  a  SPLICE  stock  point  management/quality 
control  related  application  and  one  of  the  most  recent  to 
have  successfully  completed  prototype.  STATLOC  is  a  method 
to  validate  the  physical  location  of  items.  It  is 
accomplished  through  the  reading  of  bar  coded  location  and 
stock  number  labels  of  items  in  stated  inventory  locations, 
verifying  material  present,  and  comparing  the  results  of 
these  efforts  with  that  which  is  recorded  on  UADPS-SP  master 
records.  When  discrepancies  are  uncovered,  action  is  taken 
to  correct  records  or  restore  material  in  correct  locations. 


The  benefits  that  STATLOC  is  expected  to  bring  to  the 
stock  points  include:  improved  warehousemen  productivity, 
improved  1 oc a t i o n/ i n v en to ry  record  accuracy;  the  elimination 
of  the  previous  card  oriented  location  survey  process;  and 
the  generation  of  previously  unavailable  management  reports. 
A  further  possible  benefit,  if  the  program  continues  on  its 
successful  track,  may  be  the  elimination  of  certain  annual 
wall-to-wall  inventory  requirements. 

The  current  SPLICE  STATLOC  system  is  based  upon  a 
similar  ILAP  system  developed  on  a  PDP-11/70  minicomputer 
and  prototyped  by  NSC  Norfolk.  STATLOC  was  transitioned  and 
enhanced  by  a  contractor  to  run  on  SPLICE  in  the  1984-19 J 5 
timeframe  and  was  prototyped  at  NSC  Jacksonville  in  1985. 
Subsequent  to  the  prototype,  enhancements  were  undertaken  to 
eliminate  tape  handling  and  reduce  and  consolidate  the 
number  of  transactions  required.  The  enhanced  system  is  now 
being  implemented  at  all  NAVSUP  stock  points. 

The  STATLOC  process  begins  with  the  selection  and 
generation  of  a  range  of  survey  locations  to  be  validated. 
This  was  previously  done  solely  as  a  batch  process  on  the 
Burroughs  and  a  tape  of  1 oc a t i o n / i  tern  records  produced  and 
loaded  to  the  TANDEMs.  An  alternate  process  is  now 
available  which  provides  needed  survey  data  from  terminal 
input  using  the  replicated  SPLICE  MSIR  file  and,  thus, 
reduces  Burroughs  workload. 


AD-A168  863 


AN  INTEGRATION  LONS  RANGE  PLANNING  AND  MIGRATION  GUIDE 
FOR  THE  STOCK  POIN.  .  <U>  NAVAL  POSTGRADUATE  SCHOOL 
HONTEREV  CA  H  H  BUCKLEV  ET  AL.  MAR  86 


2/3 


UNCLASSIFIED 


F/G  15/5 


JTrrr. 


Once  the  1 oc a t i o n s/ i t em s  to  be  audited  are  selected  and 
available  on  SPLICE,  a  SPLICE  terminal  is  used  to  build  load 
files  to  facilitate  further  download  of  portions  of  the 
entire  audit  range  to  TELXON  701  portable  bar  code  reading 
m  ic roc om pu t er s/ sc  an n er s  carried  by  the  warehousemen.  This 
download  is  accomplished  via  TANDEM  host  software  and  the 
RS-232  asynchronous  port  on  the  TANDEM  terminal. 
Accountability  for  which  transactions  have  been  downloaded 
and  to  which  devices  is  maintained  throughout  the  process. 

After  the  TELXON  701s  are  loaded,  warehousemen  audit 
specified  locations,  barcoding  locations  and  verifying  that 
designated  items  are  present.  Discrepancies  are  noted  and 
corrected.  When  the  audit  process  is  complete,  the  data 
stored  in  the  TELXON  701s  is  uploaded  to  the  TANDEM,  again 
via  a  terminal,  where  it  can  be  reviewed  or  edited. 
Discrepant  data  is  reformatted  into  transactions  for  furtner 
Burroughs  processing  and  currently  passed  to  the  Burroughs 
via  tape.  New  bar  coded  location  and  item  labels  may  be 
generated,  as  well  as  mandatory  ( e . g . ,  new  item  and  location 
changes,  no  material  found,  material  found  and  MSIR  zero, 
etc.)  and  optional  (e.g.,  m i s s i ng / d am ag ed  location  label, 
missing/  damaged  item  label,  etc.)  reports  produced. 

Further  information  on  STATLOC  processing  is  available  in 
[Refs  53  and  54] . 

The  residency  of  STATLOC  on  SPLICE  should  preclude  the 
need  to  migrate  it  to  the  SPAR  transition  environment. 


However,  based  upon  the  decision  to  continue  or  eliminate 
REP  FILES  during  transition,  the  range  of  location  survey 
selection  process  may  have  to  be  taken  off  SPLICE  and 
returned  to  reside  solely  on  the  new  SPAR  hosts.  Remaining 
interfaces  should  not  require  migration  to  the  SPAR 
transition  environment,  as  they  can  be  accommodated  via  tne 
SPLICE-SPAR  HYPERchannel  interface  or  can  be  easily  moved 
back  to  a  tape  interface.  STATLOC  will  require  replacement 
in  the  SPAR  modernized  UADPS-SP  system. 

STATLOC  tactically  supports  and/or  is  supported  by  the 
following  proposed  SPLICE  objectives:  6,  11,  12,  28,  29,  32, 
33,  35,  38,  41,  and  49. 

The  following  recommendations  should  be  evaluated  by  the 
LOGMARS/ SPL I CE  projects  to  assist  in  the  further  attainment 
of  corporate/ pro j ec t  goals  and  objectives: 

1.  Investigate  the  download  of  additional  portions  (or 
all)  of  the  UADPS-SP  inventory  process  (Application  I) 
to  SPLICE  to  eliminate  card  processing,  increase 
warehousemen  productivity,  increase  inventory 
accuracy,  and  capitalize  on  available  LOGMARS 
processing  technology  impl ementabl e  now  on  SPLICE. 

2.  When  available,  replace  the  Burroughs-to-SPLICE  output 
tape  interface  with  a  HYPERchannel  bulk  file  transfer 
interface. 

3.  Investigate  the  interface  and  incorporation  of  radio 
frequency  terminals  with  bar  code  readers  directly  to 
SPLICE  processors  to  eliminate  the  need  to  upload  and 
download  data  to  remote  devices. 

4.  Plan  for  the  movement  of  the  current  TAL  process  which 
transfers  data  to  the  TELXONs  to  an  intelligent 
terminal,  such  as  a  PC  interfaced  to  SPLICE  or  a 
TANDEM  DYNAMITE  workstation.  Movement  of  this  code  to 
a  PC  based  interface  makes  the  remaining  STATLOC 
processes,  written  in  TANDEM  COBOL,  more  portable  as 
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well  as  making  the  PC-TELXON  process  usable  on  any 
host  that  a  PC  can  be  interfaced  to.  Task  maintenance 
of  the  revised  TELXO N- i n te 1 1 i g en t  terminal  interface 
to  FOC. 

5.  Investigate  the  eventual  replacement  of  the  TELXO N 
devices  with  competitively  procured  lap-top  micros 
with  bar  code  readers.  Such  devices,  with  a  floppy 
disk  interface,  would  be  more  easily  interfaced  to 
intelligent  PC  wo rk s ta t i o n s  ,  thus  eliminating  the  need 
to  develop  and  maintain  Navy  unique  environmental 
software  as  required  in  the  current  interface. 

This  concludes  the  discussion  of  STATLOC.  The  next 
SPLICE  application  to  be  addressed  is  TLOO. 

G.  TRANSACTION  LEDGER  ON  DISK  ( TLOD) 

TLOD  is  an  application  that  can  easily  be  placed  either 
under  the  inventory  management  or  the  stock  point  management 
(quality  control)  functional  area.  This  is  because  the 
application  not  only  provides  a  capability  for  inventory 
managers  to  review  historical  events  for  their  material 
assets,  it  also  provides  quality  assurance  personnel 
increased  control  over  identifying  the  causes  of  and 
correcting  effects  of  material  gains  and  losses  which  result 
from  errors  in  material  management. 

The  TLOD  concept  is  simple:  have  available  for 
interactive  use,  a  one  or  two  years  history  of  a  stock 
point's  business  activities  or  transactions  (e.g.,  receipts, 
issues,  adjustment  actions,  closing  balances,  etc.).  This 
on-line  transaction  history  can  then  be  used  to  investigate 
processing  d i sc r e pa nc  i  e s  ,  particularly  those  which  result  in 


inventory  accuracy  problems,  financial  adjustments,  or  for 
other  c a u sa t i v e/ ex  pi  an  a  tor y  research  purposes. 

This  concept  was  implemented  at  least  three  times.  The 
first  time  was  a  FMSO  developed  and  released  Burroughs 
program  and  file  resident  version,  which  went  to  all  UADPS- 
SP  sites.  This  version  was  subsequently  enhanced  by  NSC 
Norfolk  personnel,  implemented  there,  and  given  to  other 
UADPS-SP  customers  who  might  desire  to  use  it.  This  second 
version  again  provided  for  Burroughs  file  residency  and 
program  processing. 

There  were  several  problems  with  both  of  these  prior 
Burroughs  TLOD  versions: 

1.  Burroughs  Host  dependence  -  This  resulted  in  two 
problems: 

a.  when  the  Burroughs  was  down,  causative  research 
stopped.  Although  this  could  be  tolerated  for 
short  periods  of  time,  the  worker  productivity 
loss  resulting  from  this  was  unacceptable. 

b.  long  response  times.  TLOD  was  not  considered  a 
"strategic"  application  to  stock  point  operations, 
in  that  it  had  few  mandatory  users.  This  resulted 
in  insufficient  processing  priorities  being 
assigned  to  it  to  get  acceptable  response  times 
and,  thus,  to  provide  for  worker  productivity. 

2.  lack  of  Burroughs  hardware  availability.  TLOD 
requires  additional  Burroughs  hardware  (i.e.,  a  great 
deal  of  disk  and  terminals)  that  was  not  immediately 
available  on  NAVSUP  contracts  or  that  would  only  be 
necessary  until  SPLICE.  This  latter  situation  made 
justification  for  this  hardware  very  difficult. 

3.  Due  to  the  inflexibility  of  the  Navy  Burroughs 
BRAM/HAM  accessing  methods,  inquiry  processing 
requiring  numerous  non-col  located  records  was  not 
efficient.  Also,  no  alternate  key  support  was 
available. 


The  third  version,  called  SPLICE  TLOD,  was  developed  by 
FMSO  i  nco  r  por  a  t  i  ng  the  Norfolk  improvements  as  well  as 
enhancing  the  system  overall  to  correct  the  above  problems. 
It  was  prototyped  along  with  SPLICE  itself  and  REP  FILES  at 
NSC  Jacksonville  in  the  fall  of  1984.  It  is  currently  being 
implemented  at  all  NAVSUP  stock  points. 

The  processing  scenario  of  SPLICE  TLOD  is  very  straight 
forward  [Refs.  55  and  56].  SPLICE  TLOD  begins  with  file 
transition  from  either  the  old  FMSO  or  Norfolk  Burroughs 
TLOD  systems  to  establish  a  SPLICE  TLOD  file  baseline. 

After  this,  daily  updates  are  applied  to  these  SPLICE 
resident  on-line  history  files  via  tapes,  which  are 
extracted  from  the  TRANSRECON  via  the  End-of-Day  processing 
string  on  the  Burroughs.  Once  this  is  completed,  users  may, 
at  will,  execute  a  series  of  nine  pre-defined  terminal 
inquiries  or  other  ad  hoc  inquiries  against  the  SPLICE  TLOD 
files  to  obtain  needed  information  to  perform  causative 
research.  Outputs  can  be  either  terminal  or  printer 
directed. 

A  second  pr e- prog  rammed  usage  of  SPLICE  TLOD  is  to 
accept  inquiry  requests  from  the  Burroughs  for  a  specific 
transaction  history  of  an  item  within  a  given  parameter 
range.  These  requests,  received  from  a  Burroughs  queue,  may 
be  passed  to  SPLICE  on-line  over  the  HYPERchannel  or  via 
tape  and,  when  processed,  result  in  a  printed  output  of  the 
requested  history.  The  printed  listing,  the  Manual  Research 


Inventory  Listing,  is  then  forwarded  to  the  customer  and 
used  for  pr e/ po s t- i nv en to r y  research. 

SPLICE  TLOD  files  are  purged  on  a  monthly  basis,  or  as 
desired,  removing  the  oldest  month(s)  or  as  directed  by  the 
users.  In  many  cases,  disk  availability  and  cost  will  oe 
the  controlling  factor,  as  it  was  in  the  decision  not  to 
mirror  SPLICE  TLOO  data  files. 

The  benefits  SPLICE  TLOO  provides  the  corporation  are 
numerous.  The  inventory  accuracy,  monetary,  and  customer 
support  benefits  provided  by  all  TLOD  versions  (i.e.,  being 
able  to  locate  misplaced  material  through  causative 
research)  are  obvious.  In  specific  reference  to  SPLICE, 
however,  SPLICE  TLOD  provides  one  of  the  means  to  assist  all 
the  stock  points  in  resolving  the  inventory  accuracy 
problem,  since  the  abundance  of  SPLICE  hardware  permits  this 
program  to  be  implemented  on  a  system  wide  basis.  Finally, 
SPLICE  TLOD  not  only  enables  users  to  research  specific 
problems,  but  also  permits  them  the  time  and  tools  with 
which  to  research  and  identify  systemic  problems. 

There  are  less  obvious  quantity  and  quality  aspects  to 
these  benefits  also.  SPLICE  TLOD  permits  users  real  time 
access  to  transaction  history  records,  thus  permitting  them 
to  process  more  causative  research  actions  in  a  shorter 
period  of  time.  SPLICE  TLOD  eliminates  the  need  for 
voluminous  paper  listings  of  transaction  history  to  be 
maintained.  Besides  its  ascetic  value,  this  paperless 


aspect  of  SPLICE  TLOD  reduces  storage  requirements  and 
decreases  lost  user  productivity  in  paging  through  mountains 
of  listing  to  find  a  single  item  or  item  history. 

Moving  now  to  the  area  of  SPLICE  TLOD  migration  need, 
several  comments  are  germane.  First,  TLOD,  regardless  of 
the  version  being  discussed,  is  inherently  tied  to  current 
Burroughs  TRANSRECON  processing.  If  during  SPAR  transition, 
TRANSRECON  maintenance  and  processing  is  perpetuated  on  the 
new  SPAR  system  or  is  performed  on  SPLICE,  SPLICE  TLOD  will 
be  able  to  obtain  its  currently  required  input  and, 
therefore,  will  not  require  migration  to  the  SPAR  transition 
environment.  If  some  other  scenario  is  planned,  a  redesign 
of  SPLICE  TLOD,  perhaps  moving  it  back  to  the  new  host 
environment,  will  be  required.  In  the  SPAR  modernized 
environment,  SPLICE  TLOO  should  be  unnecessary,  as  its 
function  will  be  performed  by  new  processing  capabilities 
planned  for  this  functional  area. 

SPLICE  TLOD  currently  supports  and/or  is  supported  by 
the  following  proposed  SPLICE  objectives:  6,  7,  11,  12,  18, 
19,  23,  29,  32,  33,  34,  35,  41,  46,  and  50. 

Concerning  recommendations  for  further  beneficial 
enhancements,  the  following  should  be  evaluated  by  the 
SPLICE  TLOD  project  to  assist  in  the  further  attainment  of 
cor por a te/ proj ec t  goals  and  objectives: 

1.  When  economically  justified,  replace  existing 

Burroughs  TLOO  terminals  with  TANDEM  6530s,  PCs,  or 
IBM  compatible  devices  to  provide  greater  terminal 
functional  ity. 


2.  When  a  3urroughs-to-SPLICE  HYPERchannel  bulk  file 
transfer  capaDil  ity  is  in  place,  eliminate  tape 
passing  from  the  Burroughs  to  SPLICE. 

3.  Investigate  tne  use  of  the  SPLICE  TRANSRECCN  to 
directly  feed  the  SPLICE  TLOD  function.  This  may  be 
done  in  conjunction  with  the  download  of  End-of-Day 
processing  to  SPLICE,  particularly  the  download  of 
program  U  A  3  2  processing. 

4.  SPLICE  TLOD  is  one  of  the  few  SPLICE  resident 
processes  that  does  not  use  mirrored  files.  If  file 
re-loads  due  to  downtime  become  a  problem,  fund 
additional  disk  in  order  to  mirror  disk  and  make  tne 
SPLICE  TLOD  function  Non-Stop. 

5.  Investigate  the  need  and  possibility  of  including 
other  SPLICE  application  history  transactions  in  the 
SPLICE  TLOD  data  base  (e.g.,  NISTARS,  NAVADS,  etc.)  to 
obtain  complete  transaction  history. 

This  concludes  the  discussion  on  SPLICE  TLOD.  The  final 
application  to  be  discussed,  UCEPS,  will  next  be  addressed. 


H.  UADPS-SP  CONTROLLED  EXCEPTION  PROCESSING  SYSTEM 

(UCEPS) 

UCEPS4?  is  a  SPLICE  based  effort  designed  to  regain 
control  of  (primarily)  Burroughs  exception  processing  at  the 
stock  points,  while  simultaneously  modernizing  this 
processing  aspect  overall.  To  understand  the  purpose  served 
and  benefits  provided  by  UCEPS,  one  must  first  understand 
what  exceptions  are  and  how  they  are  currently  handled 
within  Burroughs  UADPS-SP. 

4?UCEPS,  although  sorely  needed  at  the  stock  points,  is 
a  splinter  project  salvaged  from  a  larger  plan  to  enhance 
demand  processing  overall  on  SPLICE  in  a  standard  manner. 

The  larger  plan  was  called  Application  C  Enhanced  (ACE). 

ACE  appears  to  have  been  deferred  due  to  higher  priority 
stock  point  initiatives  (i.e.,  SPAR). 


UADPS-SP  is  a  combination  batch  oriented  and  on-line, 
time/volume  transaction  initiated  system.  When  executing  in 
either  mode,  there  are  frequently  occasions  when 
transactions  cannot  pass  programmatic  validations  ana, 
therefore,  are  rejected  for  human  intervention.  In  tne  case 
of  many  on-line  transactions,  validation  exceptions  are 
immediately  returned  to  the  user  for  correction.  If  not  an 
on-line  transaction  or,  in  some  cases,  if  an  on-line 
transaction  that  the  user  does  not  want  to  correct 
immediately,  these  "errors"  or  exceptions  to  normal 
processing  must  be  returned  to  the  user  in  some  other  manner 
for  correction  and  re-input. 

UADPS-SP  application  processes  have  four  options  to 
choose  from  in  these  cases:  1.  SPOOL  the  exception  as  a  card 
punch  file  to  disk;  2.  record  the  exception  on  the  RSF  and 
SPOOL  it  as  a  card  file  to  disk;  3.  place  the  exception  on 
the  TRANSRECON  for  punching  after  End-of-Day  processing;  and 
4.  record  the  exception  on  the  RSF  and  place  it  on  the 
TRANSRECON  for  punching  after  End-of-Day  processing. 
Regardless  of  the  method  used,  the  exception  cards  must  be 
punched  and  returned  to  the  user  from  Data  Processing  for 
correction  and  re-input. 

There  are  several  problems  with  all  of  these  approaches. 
If  the  exception  is  returned  to  the  user  on-line  (e.g.,  a 
card  image  placed  on  line  24  of  the  input  CRT  or  punched  at 
the  input  card  r e ad e r / p u nc h ) ,  the  user  may  have  to  re-input 


the  source  data  as  well  as  correct  the  error.  This  is  non¬ 
productive  and  in  many  cases  requires  the  maintenance  of 
card  reader/punch  equipment.  The  user  can  also  lose  or 
"misplace"  the  exception  entirely,  potentially  suspending 
processing  or  eliminating  processing  on  the  transaction  that 
caused  the  exception. 

The  batch  mode  of  exception  processing  is  equally 
problematic.  Cards  have  to  be  punched,  requiring  the 
maintenance  of  obsolete  mainframe  card  equipment. 

Performing  card  operations  is  a  labor  intensive  process  in 
terms  of  operational  manpower  and  computer  resources  to 
perform  T R AN SRE CON / E nd - o f -0 ay  processing.  Card  processing 
is  wasteful  of  time  in  returning  them  to  the  customer,  in 
making  many  times  minor  corrections  from  source  documents  no 
longer  held  at  the  workstation,  and  then  receiving  them  back 
from  the  customer  for  re-input.  During  this  correction 
process,  cards  also  have  a  tendency  to  get  damaged,  lost,  or 
misplaced,  which  again  may  suspend  or  terminate  transaction 

proc  ess  i  ng  .  43 

UCEPS  is  designed  to  address  all  of  these  problems.  The 
benefits  which  will  accrue  are  as  follows:  elimination  of 
obsolete  card  equipment;  controlled  access  to  and  processing 
of  exceptions  with  virtual  elimination  of  lost  records;  and 
decreased  time  to  receive,  correct,  and  turn-around 

43in  the  case  of  the  exceptions  that  are  recorded  on  tne 
RSF,  there  are  procedures  to  reproduce  the  exceptions. 


exceptions.  From  these  steps,  UCEPS  should  result  in 
earlier  problem  identification  and  greater  user 
pr  od  uc  t  i  v  i  ty  . 

The  design  of  UCEPS  is  explained  in  detail  in  [Refs.  57 
and  58]. 44  a  brief  explanation  of  proposed  processing 
follows  to  assist  the  reader  in  understanding  this 
appl  ication. 

The  key  to  developing  UCEPS  will  be  in  the  method  used 
to  forward  Burroughs  exceptions,  that  previously  went  just 
to  the  TRANSRECON,  to  a  new  SPLICE  resident  file  called  the 
Exception  Control  File  (ECF).  What  appears  to  be  proposed 
is  a  change  to  an  unspecified  Burroughs  copy  routine  "to 
send  the  exception  and  additional  information  across  the 
HYPERchannel  to  be  logged  to  a  disk  holding  device"  [Ref. 
59].  Once  on  this  SPLICE  holding  file,  another  UCEPS 
process  will  then  validate  the  exception,  primarily  as  a 
duplicate  check,  and  if  no  duplicate  exists,  place  the 
record  in  a  SPLICE  ECF  for  on-line  correction  by  applicable 
application  personnel  and  for  statistical  reporting. 

Associated  processing  improvements  also  to  be  provided 
include: 

1.  on-line  inquiry  and  correction  of  entries  on  the  ECF. 
Exceptions  may  be  worked  as  groups  or  on  an  individual 
basis,  by  applications  area.  Corrected  exceptions 
will  be  forwarded  back  to  the  Burroughs  on-line  and 


44[}oth  of  these  references  are  draft  documents, 
therefore,  final  processing  may  be  modified  as  a  result  of 
the  t e s t i ng / d ev e 1 o pm en t  process. 


deleted  from  the  ECF  and  placed  in  an  appropriate 
nistory  file  ( i . e . ,  Exception  History  File  (  E  H  F  )  )  . 

2.  a  narrative  explanation  of  exceptions  being  w o  r  '<  e  a  to 
suoplement  tne  two  character,  often  cryptic,  cooes 
currently  generated.  This  system  narrative  file  will 
also  be  supplemented  by  a  local  narrative  file  £or 
site  specific  comments  and  instructions. 

3.  a  re-cycle  capability  to  automatically  forwar: 
exceptions  back  to  tne  source,  wnen  tne  exception 
generated  was  due  to  a  time  related  file  condition  ano 
the  only  exception  processing  required  is  re-input  at 

a  later  date. 

4.  UCEPS  file  maintenance  (e.g.,  history  purges, 
narrative  file  updates,  etc.). 

5.  exception  report  generation  (e.g.,  audit  trail, 
statistical,  workload,  turn-around  time,  etc.). 

These  improvements  will  initially  be  available  to 

Application  C  (Demand  Processing)  programs,  then  to  nine 

other  Burroughs  applications.  SPLICE  resident  applications 

will  also  be  provided  "hooks"  into  the  UCEPS  files  so  that  a 

single  exception  system  will  be  available  for  all  UADPS-SP 

user  applications,  regardless  of  program  or  processing 

location. 

The  need  and  potential  for  migrating  the  functions  of 
UCEPS  to  the  SPAR  transition  environment  will  not  exist  if 
SPAR  will  allow  " en v i r o nm en ta 1 "  software  to  be  written  and 
called  by  applications  to  enable  them  to  pass  exception 
transaction  images  over  the  HYPERchannel  to  SPLICE,  so  that 
ECF  updating  can  continue  there.  If  no  environmental 
software  is  written  to  do  this,  UCEPS  will  have  to  be  re¬ 
designed  and  r e- im pi em en ted  on  the  new  SPAR  hardware  prior 
to  transition  system  implementation.  Under  SPAR 


modernization,  UCEPS  should  be  suDsumed  by  new  SPAR  on-line 
transaction  processing  metnods  and,  thus,  eliminated  from 
SPLICE. 

SPLICE  UCEPS  is  supported  by  and/or  supports  tne 
following  proposed  SPLICE  project  ODjectives:  12,  19,  23, 
24,  29,  32,  33,  34,  35,  41,  and  45. 

There  are  several  recommendations  that  the  authors  nave 
concerning  UCEPS  to  enable  it  to  provide  even  greater 
support  to  the  corporation: 

1.  Modify  the  same  copy  routines  used  to  accomplisn 
SPLICE  TRANSRECON  Offload  to  accommodate  UCEPS. 

a.  At  a  site  where  the  TRANSRECON  is  being  maintained 
on  SPLICE,  modify  the  file  replicator  software  on 
TANOEM  to  place  exceptions  from  the  SPLICE 
TRANSRECON  onto  the  holding  file  that  is  the  input 
to  the  UCEPS  ECF.  This  eliminates  duplicate 
exception  images  having  to  be  sent  down  the 
HYPERchannel  to  SPLICE  (i.e.,  once  for  SPLICE 
TRANSRECON  Offload  and  once  for  ECF  input). 

b.  At  a  site  where  the  TRANSRECON  is  being  maintained 
solely  on  the  Burroughs,  optionally  do  not  record 
exceptions  on  the  TRANSRECON.  When  the  option  is 
taken  not  to  record  the  exception  on  the  Burroughs 
TRANSRECON,  send  the  transaction  down  the 
HYPERchannel  to  the  SPLICE  UCEPS  process.  If 
exceptions  are  still  to  be  recorded  on  the 
Burroughs  TRANSRECON,  do  not  implement  UCEPS 
without  a  thorough  Burroughs  capacity  study. 45 

2.  For  on-line  Burroughs  applications  which  return  errors 
immediately  to  the  user,  evaluate  the  need  to  place  an 

4^When  the  TRANSRECON  remains  on  the  Burroughs  and 
exceptions  are  written  to  it,  that  requires  Burroughs 
overhead.  If  this  is  done  AND  another  image  of  the  same 
exception  must  be  written  to  the  HYPERchannel,  that  adds 
additional  Burroughs  workload  which  is  not  being  compensated 
for  via  workload  off-load.  Prior  to  doing  this,  a  capacity 
study  for  the  site  must  be  undertaken  to  ensure  that  the 
benefits  from  implementing  UCEPS  will  outweigh  the  costs. 


information-only  record  of  the  exception  on  tne  UCEPS 
ECF  or  EHF. 


a.  In  some  Burroughs  applications  (  i .  e .  ,  Application 
N  UN  50),  the  on-line  validation  programs  appear  to 
return  exceptions  to  the  input  terminal  Pased  upon 
the  terminal  mode  the  user  is  in  (i.e.,  in  frames 
mode,  to  line  24;  in  Roll  Down  Input  Top  (RDIT) 
mode,  to  the  top  of  the  screen).  Exceptions  may 
still  be  lost  here  due  to  user  error  or  if 
exceptions  roll  off  the  screen. 

b.  The  proposed  ECF  or  EHF  information-only  image  of 
the  exception  may  be  the  only  place  to  recover  the 
lost  exception  and  perhaps  the  entire  transaction. 

3.  UCEPS  is  being  implemented  in  a  phased  approach, 
starting  with  Application  C.  Rather  than  continuing 
with  Burroughs  applications,  consideration  should  be 
given  to  next  developing  the  UCEPS  interface  to  other 
SPLICE  resident  applications,  particularly  those 
currently  in  design  or  development  (i.e.,  APADE  or 
SPLICE  ABE).  In  this  way,  UCEPS  interfaces  could  be 
implemented  while  the  application  is  under 
development,  vice  requiring  a  major  maintenance  action 

1  a  ter . 46 

4.  Investigate  the  incorporation  of  other  system 
exceptions  into  UCEPS.  Specifically,  NISTARS  and 
NAVSCIPS  exceptions  should  be  considered. 

5.  Do  not  let  the  successful  implementation  of  UCEPS 
become  the  only  portion  of  ACE  to  be  implemented  on 
SPLICE.  There  are  simply  too  many  benefits  available 
to  the  corporation  from  implementing  ACE,  particularly 
if  SPAR  transition  funding  is  curtailed,  to  permit  its 
demise.  At  a  minimum,  a  method  must  be  provided  to 
issue  material  and  generate  DD-1348-ls,  including  bar 
code  data,  on  the  SPLICE  system  using  the  replicated 
MSIR  as  the  source  when  the  Burroughs  is  down.  All 
such  issues  must  be  locally  recorded  on  SPLICE, 
without  changing  the  quantity  on  the  replicated  MSIR, 
and  transactions  collected  to  forward  back  to  the 
Burroughs  to  update  the  master  MSIR. 


46jhis  recommendation  is  being  provided  because  in  no 
other  application  documentation  reviewed  for  this  thesis  was 
there  any  mention  of  an  UCEPS  interface.  Hopefully,  this  is 
merely  an  oversight. 


d 


These  recommendations  conclude  both  the  discussion  of 
UCEPS  and  this  chapter  on  centrally  developed  SPLICE 
applications.  The  next  area  to  be  addressed  will  be  locally 
developed  SPLICE  applications  and  their  support  of  corporate 
and  project  plans. 


V.  LOCALLY  DEVELOPED  SPLICE  APPLICATIONS 


A.  CHAPTER  OVERVIEW 

The  contagion  concept  described  by  Nolan  and  Gibson 
[Ref.  60],  also  referred  to  as  the  technology  learning  and 
adaptation  concept  by  Cash,  McFarlan,  and  McKenney  [Ref. 

61],  is  at  work  today  at  the  stock  points  who  have  received 
their  SPLICE  hardware.  Essentially,  both  these  concepts 
describe  a  phase  of  ADP  technology  infusion  where  users  have 
received  systems  to  perform  some  initial  tasks  and  have 
themselves  discovered  other  productivity  enhancing  tasks 
that  the  same  systems  can  also  perform.  When  users  have 
demonstrated  that  these  additional  endeavors  promise  high 
payback  for  minimal  investment  and  are  permitted  to  pursue 
them,  substantial  unexpected  paybacks  can  accrue  to  the 
organization.  Once  this  situation  is  identified,  it  is 
management's  job  to  exploit  these  paybacks  through 
organization  wide  dissemination  of  the  new  uses  for  the 
tec  hnol ogy  . 

This  chapter  deals  with  three  locally  developed  SPLICE 
applications  that  fit  this  mold.  All  three  were  implemented 
with  minimal  initial  investment  and  can  have  applicability 
across  all  stock  points.  The  authors  intent  in  describing 
these  initiatives  is  to  make  the  corporation  aware  of  these 


"home  grown"  initiatives  on  SPLICE,  in  the  hope  that  they 
will  be  applied  stock  point  wide  to  attain  corporate  goals. 

The  first  application  to  be  discussed  deals  with  a 
TANDEM  based  Electronic  Transfer  of  Funds  (EFT)  application 
to  Federal  Reserve  Banks  (FRBs)  for  civilian  payrolls.  Tne 
second  local  unique  application  is  a  method  for  entering 
payroll  data  via  SPLICE  terminals  instead  of  punched  card  or 
non-standard  key- to- tape/ key- to-d  i  sk  systems,  as  is 
currently  done  by  the  many  of  the  stock  points. 47  The  last 
application  is  an  approach  to  interim  stock  point  office 
automation  that  has  been  successfully  prototyped  at  NSC 
Pearl  Harbor . 

B.  ELECTRONIC  FUNDS  TRANSFER  (EFT) 

EFT  is  a  very  expeditious  way  to  get  payroll  data  to  the 
regional  FRBs  for  further  distribution  to  employees'  direct 
deposit  accounts  at  designated  financial  institutions.  The 
Treasury  of  the  United  States  informed  all  government 
agencies  in  1983  that  EFT  is  the  preferred  method  of  making 
payment  of  recurring  benefit  and  salary  payments  through  its 
Direct  De po s i t/ E 1 ec tro n i c  Funds  Transfer  (DD/EFT)  program. 
[Ref.  62] 

47It  had  been  the  authors'  intention  to  also  address  the 
joint  NSCs  Nor fol k/Pearl  Harbor  Source  Data  Automation  (SDA) 
project  using  SPLICE,  which  has  only  recently  been 
documented.  U n f o r t u n a t el y ,  required  documentation  on  this 
initiative  was  not  received. 


Under  DD/EFT,  a  disbursing  office  through  its  ADP 
processing  activity  sends  its  civilian  mechanized  payment 
data  to  the  local  servicing  FRB,  two  to  three  days  before 
each  payday.  The  data  may  oe  delivered  on  magnetic  tape  via 
mail  or  courier,  or  transmitted  via  telecommunications  from 
the  submitting  activity.  The  FRB  will  strip  away  the 
payments  going  to  the  institutions  it  serves  and  then  send 
the  remainder  of  the  pay  data  to  the  FRB’s  automated 
Clearing  House  for  further  dissemination  to  non-serviced 
institutions. 

Most  stock  points  are  taking  advantage  of  DD/EFT  today 
by  submitting  their  payroll  information  through  magnetic 
tape  sent  via  mail  or  couriers  to  the  FRBs,  since  the 
Burroughs  cannot  support  the  appropriate  protocols  to  send 
this  data  via  telecommunications.  There  are  several 
problems  with  this  approach,  however.  First,  the  batch 
oriented  non-Navy  standard  payroll  process  used  today  at 
stock  points  often  results  in  late  payroll  runs  or  re-runs. 
With  the  requirement  to  have  DD/EFT  data  to  the  FRBs  several 
days  before  a  required  payday,  any  problems  experienced 
processing  the  payroll  leaves  little  time  left  to  physically 
move  tapes  to  FRBs.  Secondly,  many  of  the  stock  points  are 
in  areas  that  periodically  experience  incapacitating 
weather.  In  such  cases,  delivery  of  tapes  might  also  be 
delayed.  Finally,  both  the  mail  and  courier  services  are 


subject  to  holiday  workloads,  inadvertent  package  losses, 
and  theft. 

To  overcome  these  shortcomings,  NSC  Norfolk  has 
developed  a  DD/EFT  data  communications  transmission 
procedure  using  SPLICE.  The  procedure  is  simple.  Payroll 
data  on  tapes  from  Burroughs  Application  K  are  taken  to  the 
SPLICE  TANDEM  where  it  is  loaded  to  disk,  after  resolving 
the  data  format  i  neon s i stenc  ie s  between  the  two  systems. 

Then  a  process  is  run  which  inserts  data  communications 
control  characters  in  the  data,  as  required  by  the  FRB.  To 
commence  data  transfer,  the  NSC  calls  the  FRB  to  request 
permission  to  transfer.  The  FRB  then  establishes  connection 
to  the  TANDEM  system  via  a  4800  bit  per  second  line.  When 
connection  is  established,  the  NSC  executes  a  TAL 
application  which  interfaces  to  the  TANDEM  ENVOY  data 
communications  software  and  sends  the  payroll  data.  After 
the  transmission  is  accomplished  the  FRB  will  call  the  NSC 
for  a  verification  of  the  number  of  records  sent  and  totals 
of  the  payroll  transmitted. 

The  SPLICE  TANDEM  system  configuration  required  to 
implement  this  application  is  equally  simple.  A  data 
communications  line  must  be  available  from  the  FRB  to  the 
TANDEM  and  configured  on  the  TANDEM  system  as  a  point-to- 
point  line  using  a  bisynchronous  protocol  provided  in  ENVOY 
and  connected  to  a  byte-synchronous  controller.  All  of 


these  components  are  available  from  the  SPLICE  contract. 

The  NSC  TAL  application  is,  obviously,  Navy  unique. 

Tne  benefits  to  the  corporation  from  this  simple 
application  at  NSC  Norfolk  are  threefold.  First,  there  is 
an  elimination  of  some  manual  operation  in  the  secure 
delivery  of  payroll  data,  which  should  result  in  some 
monetary  savings  (i.e.,  couriers).  Secondly,  since  its 
takes  less  time  to  physically  transmit  the  payroll  data, 
less  lead  time  is  required  by  Data  Processing  to  receive  the 
payroll  outputs.  This  time  differential  is  available  to  be 
used,  when  necessary,  to  accommodate  batch  payroll  process 
re-runs  or  late  runs.  And  thirdly,  the  system  has  been 
implemented  without  the  need  to  use  scarce  FMSO  CDA 
development  resources  and  is  now  available  to  other  stock 
points  at  1 i ttl e  cost . 

Concerning  migration  to  the  SPAR  environment,  the 
authors  believe  that  a  need  exists  to  have  a  similar 
facility  available  at  the  stock  points  during  both  phases  of 
SPAR.  During  the  transition  phase  of  SPAR,  SPLICE  can 
perform  this  function  for  customers  having  SPLICE  hardware 
and  in  behalf  of  customers  who  do  not.  One  would  assume 
that  SPAR  modernization  should  not  need  to  be  concerned  with 
this  requirement  in  that  the  Navy  Standard  Civilian  Payroll 
System,  NAVSCIPS,  is  assuming  the  payroll  processing 
requirement  from  UADPS-SP.  However,  as  will  later  be  seen 
in  Chapter  VI,  a  SPLICE  or  its  successor  system  will  still 


be  required  to  perform  the  transfer  function,  unless 
NAVSCIPS  assumes  this  role  directly. 

The  last  area  that  will  be  addressed  under  this 
application  is  how  the  EFT  process  tactically  supports  or 
can  be  made  to  better  support  the  proposed  SPLICE 
objectives,  thereby  supporting  previously  presented 
corporate  and  project  goals  and  strategies.  The  EFT  process 
directly  supports  the  following  proposed  SPLICE  project 
objectives:  8,  9,  12,  15,  19,  27,  29,  32,  35,  and  36. 

To  better  achieve  these  objectives,  the  following 
recommendations  should  be  considered: 

1.  The  NSC  Norfolk  EFT  system  should  be  enhanced  to  use 
the  HYPERchannel  to  pass  the  outgoing  bulk  file 
payroll  data  from  the  Burroughs  to  the  SPLICE  system 
and  further  improved  to  eliminate  the  required  calls 
made  back  and  forth  between  the  stock  point  and  FRB. 

A  mutually  agreed  upon  security  system  with 
verification  and  automatic  call  back  could  accomplish 
this  second  suggestion. 

2.  The  enhanced  NSC  Norfolk  EFT  system  should  be 
designated  the  stock  point  standard  system,  and 
implemented  at  all  stock  points  within  local  data 
communications  range  of  FRBs.  NSC  Norfolk  will  remain 
lead  CDA  for  the  system. 

3.  Gateways  to  FRBs  at  the  SPLICE  sites  within  the 
vicinity  of  FRBs  should  be  established  so  that  other 
stock  points  can  also  pass  their  payroll  data  to  FRBs 
via  SPLICENet. 

4.  If  NAVSCIPS  fails  to  provide  similar  EFT  transmission 
capabilities,  the  SPLICE  EFT  system  should  be  used  to 
accomplish  this  function,  as  a  back-end  process  to 
NAVSCIPS. 

If  these  recommendations  are  implemented,  this  simple  local 
application  can  easily  be  made  to  be  the  standard  UADPS-SP 
DD/EFT  interface  to  the  FRBs  and  enable  the  benefits  that 


NSC  Norfolk  receives  from  it  to  be  shared  by  all  stoc< 
po  i  n t  s  . 

This  concludes  the  discussion  of  EFT  processing.  The 
next  local  application  to  be  addressed  is  tne  NSC  Norfolk 
Payroll  Processing  System. 

C.  PAYROLL  PROCESSING  SYSTEM 

As  will  be  discussed  in  the  next  chapter,  payroll 
processing  within  the  Navy  today  is  performed  by  numerous 
"standard"  and  local  systems.  One  of  the  requirements 
common  to  each  of  these  systems  is  the  need  to  get  the  time 
and  attendance  (T/A)  data  into  the  processing  systems.  At 
many  stock  points  today,  this  is  accomplished  by  using  a 
myriad  of  no n- stand ard  i  zed  keypunch,  key-to-tape,  or  key-to- 
disk  systems.  At  the  NAVSUP  stock  points,  the  output  from 
these  processes  are  uniformly  fed  as  inputs  to  Application  K 
on  the  Burroughs  systems. 

Several  problems  result  when  standard  inputs,  in  this 
case  payroll  T/A  inputs,  must  be  generated  from  non-standard 
systems.  First,  a  prol  i  feration  of  hardware  types  results 
making  support,  maintenance,  and  replacement  very  difficult, 
as  well  as  uneconomical.  Secondly,  multiple  software 
applications  to  assist  users  in  inputting  data  in  required 
formats  must  be  obtained,  maintained,  and  interfaced  to 
other  systems.  In  the  environment  we  face  today,  this 
directly  results  in  duplicate  and  unnecessary  software 


development  and  maintenance  manpower  costs,  particularly  if 
input  requirements  change,  as  they  will  under  NAVSCIPS. 

The  Payroll  Processing  System  (PPS)  developed  by  NSC 
Norfolk  on  SPLICE  addresses  both  of  these  problems  and 
provides  as  a  very  efficient  way  of  getting  standard  input 
into  the  current  UADPS-SP  payroll  system  via  terminal  entry. 
This  system  is  applicable  to  UADPS-SP  payroll  processing 
today,  and  as  is  address ed  in  the  next  chapter,  will  be 
equally  applicable  after  the  implementation  of  NAVSCIPS  in 
late  1986  or  early  1987. 

The  NSC  Norfolk  PPS  process  is  started  by  a  program  on 
the  Burroughs,  that  when  called,  creates  and  downloads 
payroll  skeleton  payroll  records  to  an  unlabeled  tape.  The 
unlabeled  tape  is  then  taken  to  and  loaded  on  the  SPLICE 
system  by  a  program  called  PAYLOAD.  PAYLOAD  purges  the  data 
in  the  current  PPS  payroll  data  files  and  loads  the  skeleton 
records  in  their  place.  These  skeleton  records  are  then 
ready  for  terminal  update  by  the  payroll  department  using 
TANDEM  PATHWAY  screens  painted  specifically  for  this  update 
process  and  the  time/labor  cards  manually  completed  by 
employees.  [Ref.  63] 

After  the  payroll  department  has  completed  entering  all 
the  current  pay  period  data,  a  second  program,  called 
PAYCARD,  takes  the  input  data  and  generates  a  card  image 
file  which  can  be  dumped  to  tape  and  fed  into  the  Burroughs 
Application  K  payroll  process.  From  this  point  on  the 


Burroughs  processes  the  payroll  data  as  if  it  had  been  input 
directly  to  it  via  cards. 

There  are  several  benefits  that  this  simple  application 
has  provided  NSC  Norfolk.  In  using  this  PPS  application  tne 
NSC  has  eliminated  the  need  for  punched  cards  or  non¬ 
standard  key-to-tape  type  equipment  for  payroll;  only  the 
standard  SPLICE  equipment  need  be  used.  This  system  has 
eliminated  the  need  to  send  this  data  to  an  area  other  than 
payroll  for  media  change  (i.e.,  from  sheets  of  paper  to 
punch  cards)  and  input.  Keeping  the  data  within  the  payroll 
section  adds  more  security  (i.e.,  less  chance  for 
unauthorized  changes  or  data  loss)  to  the  system  and  permits 
the  payroll  clerks  themselves  to  input  the  payroll 
information  instead  of  wasting  time  having  to  manually 
prepare  forms  for  someone  else  to  use.  This  process  has 
also  permitted  errors  to  be  corrected  on-line  as  they  occur, 
instead  of  having  to  review  and  return  inputs  to  another 
section  for  later  correction.  Finally,  this  new'process 
permits  more  time  for  payroll  clerks  to  audit  payroll  data 
instead  of  merely  having  time  to  locate  keyed  errors  that 
result  from  the  card  generation  process  and  the  illegibility 
of  the  writing. 

PPS,  like  EFT  discussed  above,  should  not  pose  a  problem 
to  SPAR  during  its  transition  phase,  if  the  system  is 
uniformly  implemented  on  SPLICE  at  all  stock  points.  In  the 
event  it  is  not,  SPAR  will  face  the  replacement  or  interface 


of  card  and  key-to-tape  or  disk  systems  to  the  new  naroware 
and  transitioned  programs.  In  that  NAVSCIPS  does  not 
directly  provide  for  the  input  of  T/A  data,  SPLICE  or  its 
successor  system,  appears  to  be  required  to  provide  this 
function  under  SPAR  modernization. 

The  final  area  that  will  be  addressed  is  how  PPS 
tactically  supports  or  can  be  made  to  better  support  the 
proposed  SPLICE  objectives,  thereby  supporting  corporate  and 
project  goals  and  strategies.  PPS  directly  supports  and/or 
is  supported  by  the  following  SPLICE  project  objectives:  9, 
12,  27,  29,  32,  33,  35,  and  36. 

Although  PPS  is  a  local  system,  it  has  the  potential  for 
use  stock  point  wide  and  providing  support  for  corporate 
goals  and  the  SPLICE  objectives  listed  above.  To  this  end, 
the  following  recommendations  are  made  concerning  PPS: 

1.  That  PPS  be  designated  as  the  standard  payroll  pre¬ 
processing  system  for  the  UADPS-SP  community  and 
implemented  system  wide  on  already  available  SPLICE 
equipment.  NSC  Norfolk  will  remain  CDA.  This  move, 
when  followed  by  similar  cardless  environment  and  SDA 
projects  (i.e.,  UCEPS  and  the  emerging  NSCs 

Norfol k/Pearl  Harbor  SDA  orojects),  should  eliminate 
the  need  for  non-standard  source  input  equipment, 
support  a ppl i c a t i o n s ,  and  interfaces  to  other  systems. 

2.  That  PPS  output  formats  be  modified  to  the  NAVSCIPS 
input  format  when  that  system  is  delivered  to  the 
field  and  serve  as  the  stock  point  standard  T/A  data 
input  mechanism  under  that  system. 

That  in  the  interim  to  NAVSCIPS,  improvements  be  made 
to  PPS  to  enable  file  passing  between  SPLICE  and  the 
Burroughs  via  H Y P E R c ha n n e 1  ,  eliminating  the  need  for 
manual  tape  operations. 


3. 


T  n  i  s  concludes  t  n  e  discussion  on  PPS.  The  NSC  Pearl 
Haroor  Office  Automation  initiative  will  be  aacressec  next. 

D.  OFFICE  AUTOMATION  INITIATIVES 

Office  Automation  (OA)  can  be  defined  as  tne  automating 
ano  linking  of  nine  functions:  stand  alone  computing,  word 
processing,  graphics,  electronic  s pr e ad s n e e t s  ,  personal  data 
base  management,  personal  management  (i.e.,  calendars, 
telepnone  directories,  etc.),  a  computer  with  communications 
capabilities  for  access  to  and  source  data  automation  of 
mainframe  applications  to  improve  efficiency,  and  a  window 
to  data  sources  both  internal  and  external  to  the 
organization  [Ref.  64].  To  a  great  extent  within  the  stock 
point  community,  OA  appears  to  have  been  left  as  a  local 
prerogative  in  the  interim  to  SPAR.  48  The  result  of  this 
has  been  a  concentration  solely  on  local  (i.e.,  command) 
word  processing,  using  whatever  money,  hardware,  and 
software  that  the  site  could  obtain  (i.e.,  Productivity 
Enhancing  Capital  Investment  (PECI)  funds). 

Although  not  within  the  project  charter,  with  SPLICE,  it 
is  possible  to  develop  and  implement  a  standard  stock  point 
OA  function,  covering  all  of  the  above  processing  areas 
under  the  current  SPLICE  contract.  With  some  additional 

48[his  is  a  conclusion  on  the  part  of  the  authors.  It 
is  based  upon  t-o  facts:  1.  there  is  no  OA  standard  nardware 
or  application  software  in  UAOPS-SP,  and  2.  the  inventory  of 
the  stock  point  OA  stand  alone  equipment  includes  WANG, 

XEROX,  NBI,  and  IBM  (all  procured  locally). 


efforts,  this  standard  interim  stock  point  OA  system  could 
be  made  to  interface  with  tne  other  existing  major  OA 
initiative  within  NAVSUP:  the  ICP  system.  The  lead 
organization  for  this  effort  has  been  NSC  Pearl  Harbor 
( NSCPH ) . 

The  NSCPH  Data  Processing  Department  analyzed  tne  nine 
OA  functional  areas  and  determined  that  all  of  these 
functions  could  be  provided  by  SPLICE  on  a  phased  basis 
using  an  integrated  micro  based  system  to  distribute 
functions,  instead  of  performing  all  these  functions  on  a 
mainframe.  In  Phase  I,  s t and  a rd i za t  i  o n  of  m icrocomputer 
hardware  and  software  would  be  undertaken,  to  perform  local 
word  processing,  data  base,  local  graphics,  spread  sneet 
calculations,  and  other  desired  personal  computing.  The 
second  phase  would  provide  for  local  site  shared  disk 
storage,  shared  text  files,  shared  peripherals,  interface  to 
the  TANDEM  hosts  for  multiple  host  access  and  source  data 
automation,  and  the  addition  of  E-MAIL.  The  third  phase 
would  provide  the  ability  to  share  the  documents  and  mail 
created  locally  with  other  users  using  the  same  products  on 
remote  systems  linked  by  telecommunications  and  to  achieve 
full  i n ter o per ab i 1  i  ty  through  DDN.  [Ref.  65] 

NSCPH  initiated  Phase  I  with  the  procurement  of  45 
TANDEM  DYNAMITE  microcomputers,  each  with  256KB  of  RAM  and 
dual  360K8  disk  drives.  These  m i c r oc om p u t er s  are  IBM  PC 
compatible  and  were  selected  over  other  IBM  compatible  PCs 


to  provide  for  dual  usage  of  these  devices  (i.e.,  as  PCs  and 
as  TANDEM  6530  terminals)  in  other  phases.  Most 
workstations  included  printers  for  single  workstation  use. 
Software  selected  included:  dBase  III,  Lotus  1-2-3,  and 
Multimate  Advantage.  The  former  two  packages  were  selected 
as  they  are  established  industry  leaders;  the  latter  for  its 
ease  of  use  and  support  for  the  IBM  Document  Content 
Archi tecture. 

The  second  Phase,  which  was  implemented  six  months 
later,  consisted  of  the  connection  of  the  DYNAMITE 
workstations  to  the  TANDEM  hosts  as  6530  terminals  using 
standard  TANDEM  point-to-point  protocols.  This  step 
enabled:  the  introduction  of  local  source  data  automation 
initiatives  from  these  terminals;  E-MAIL  using  TANDEM'S 
TRANSFER/ MAIL  product  between  d epar tmen t s ; 49  and  the 
interfacing  of  other  PCs,  sharing  of  TANDEM  host  printers, 
and  the  exchanging  of  files  among  existing  DYNAMITE  PCs 


49TRANSFER/MAIL  will  be  upgraded  to  the  new  TANDEM  PS 
Mail  product  in  the  near  future.  PS  Mail  is  a  software 
product  that  will  let  you  draft  memos  and  send  them  along 
with  other  documents  to  users.  PS  Mail  is  a  full  service 
electronic  mail  system  that  guarantees  delivery  of  mail  and 
interfaces  with  Tandem  653x,  IBM  3 2  7  x  ,  and  asynchronous 
(TTY)  terminals,  personnel  computers,  and  Group  3  facsimile 
machines.  This  software  is  menu  driven  and  gives  both  full 
screen  display  and  on-line  help.  [Ref.  66] 


using  TANDEM'  s  PC  LINK  software. 50  i n  this  phase,  NSCPH 
also  planned  to  eliminate  its  Xerox  860  word  processing 
system. 

The  final  phase,  which  will  be  implemented  in  the  near 
future,  will  consist  of  connecting  the  NSCPH  SPLICE  system 
to  the  DON  via  SPLICENetSl  to  enable  users  to  access  other 
SPLICE  system  applications,  pass  data  or  files,  and  use  E- 
M  A I L  to  converse  with  other  activities  on  SPLICE.  At  some 
point,  when  full  DDN  i n t e ro per ab  i  1 i t y  is  provided  by  SPLICE, 
these  capabilities  are  expected  to  be  usable  in  interfacing 
with  NAVSUP  and  DDN  subscribers  using  standard  DDN  service 
protocols.  A  WANG  system  used  in  the  NSCPH  Joint  Personnel 
Property  Support  Office  would  be  eliminated  in  this  phase. 
[Ref.  68] 

In  the  opinion  of  the  authors,  the  NSCPH  plan  for 
implementing  0A  at  its  site  can  serve  as  the  basis  for  an 
interim  standard  0A  function  at  the  all  stock  points.  There 
are  several  areas  in  this  plan  that  require  further 
definition  and  others  where  improvements  can  be  made. 

50pc  Link  allows  users  to  do  the  file  interchange 
functions  with  the  TANDEM  hosts  or  each  other  while  using 
DYNAMITE  workstations  or  IBM  PC  compatible  computers.  It 
also  allows  the  IBM  PC  compatibles  to  emulate  both  Tandem 
6530  and  IBM  3270  terminals.  Any  document  created  on  a  PC 
can  be  loaded  up  to  the  host  and  then  shared  by  multiple 
users.  The  commands  to  do  these  functions  are  MS-DOS 
commands  so  user's  need  not  learn  new  commands  and  can  use 
the  TANDEM's  mirrored  disks  as  their  hard  disk.  [Ref.  67] 

51-See  Chapter  VII  for  further  details  on  SPLICENet. 


However,  the  basic  plan  appears  sound  for  an  interim  OA 
system.  These  areas  will  be  elaborated  upon  in  the 
recommendations  section  for  this  application. 

The  benefits  that  are  accruing  to  NSCPH  and  can  accrue 
to  the  corporation  if  this  basic  plan  were  adopted  at  all 
SPLICE  sites  are  as  follows:  increased  white  collar 
productivity,  decreased  paper  generation  for  own-site  and 
inter-system  mail  and  reports,  s t and  a rd i z a t  i  o n  of  interim  OA 
initiatives  requiring  a  single  replacement  strategy  by  SPAR, 
and  reduced  telecommunications,  terminal,  and  peripheral 
costs  through  the  introduction  of  multifunction  workstations 
that  can  share  resources  and  SPLICENet. 

If  such  as  system  were  adopted  stock  point  wide,  the 
need  to  address  OA  functions  during  SPAR  transition  would  be 
eliminated.  SPLICE  would  be  available  to  fulfill  this  role 
until  the  SPAR  modernization  effort  were  sufficiently  along 
that  stock  point  OA  could  be  addressed  as  a  separate  issue, 
when  appropriate  for  SPAR  during  modernization,  it  could 
then  address  the  replacement  of  stock  point  OA  functions 
concurrent  with  addressing  SPLICE  replacement. 

The  final  area  that  will  be  addressed  is  how  Office 
Automation  tactically  supports  or  can  be  made  to  better 
support  the  proposed  SPLICE  objectives,  thereby  supporting 
previously  presented  corporate  and  project  goals  and 
strategies.  Office  Automation  directly  supports  and/or  is 


supported  by  the  following  SPLICE  project  objectives:  1,  12, 
13,  14,  15,  16,  19,  23,  25,  29,  32,  33,  34,  35,  41,  and  45. 

There  are  six  recommendations  that  the  authors  have  that 
could  improve  this  application  to  increase  corporation 
benefit,  assuming  that  it  is  accepted  as  the  interim  stock 
point  OA  system.  These  are: 

1.  It  may  be  more  cost  effective  to  implement  local  area 
networks  (LANs)  of  PCs  instead  of  using  point-to-point 
data  communications  and  DYNAMITE  workstations. 
Consideration  should,  therefore,  be  given  to  using  the 
recently  announced  TANDEM  PC  LAN  interface  product  in 
lieu  of  the  current  NSCPH  connection  method  for  future 
implementations  not  using  DYNAMITE  workstations. 

2.  Standards  need  to  be  established  concerning  word 
processing  document  storage  and  interchange  formats, 
particularly  in  light  of  plans  to  move  documents 
intra-site  and  inter-site.  The  standard  Multimate 
format  may  be  acceptable  for  all  PCs  using  Multimate 
on  a  departmental  system,  but  this  format  is  too 
restrictive  outside  of  this  environment.  Storage  of 
documents  in  Document  Content  Architecture  format,  a 
Multimate  option,  is  recommended  for  documents  to  be 
stored  for  later  revision  or  shared  use  on  TANDEM 
disks,  as  well  as  for  usage  by  the  TANDEM  word 
processor  T-TEXT/PS  TEXT  and  for  those  documents  being 
moved  throughout  the  SPLICE  system  or  to  other 
systems.  Document  Interchange  Architecture  format 
should  be  used  for  inter-system  interchanges. 

3.  Gateways  will  need  to  be  established  for  documents 
being  sent  to  non-SPLICE  systems,  particularly  to  the 
ICPNet  E-MAIL  system  or  at  the  NARDACs  to  the 
SperryLink  system.  FDC  (or  TANDEM  through  FDC)  should 
be  tasked  to  develop  the  TRANSFER  client  servers  or 
other  processes  needed  to  transform  SPLICE  produced 
documents  stored  in  DCA/DIA  formats  to  both  of  these 
systems  and  incorporate  the  inter-net  transmission 
requirements  into  their  SPLICENet  proposal. 

4.  The  NSCPH  proposal  does  not  address  standardization  of 
PC  graphics  packages  (beyond  LOTUS  1-2-3)  or  personal 
support  packages  such  as  calendars.  Standards  should 
be  established  for  all  software  products  to  be  used. 
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5.  If  the  NSCPH  proposal  is  accepted  for  corporate  stock 
point  use,  bulk  site  licensing  or  corporate  quantity 
purchases  should  be  pursued  to  generate  savings  over 
buying  PC  software  packages  individually.  Network 
system  discounts  should  also  be  pursued  in  that  both 
local  PC  networks  with  system  servers  can  be 
implemented  to  store  software  and  the  TAN  OEM  host 
system  itself  can  store  software  for  connected  PCs 
through  the  TANDEM  host  FILE  SERVER  software  package. 

6.  NAVSUP  itself  is  not  a  planned  SPLICE  site/user, 
although  it  will  probably  be  the  intended  recipient  of 
much  of  the  stock  point  E-MAIL  traffic.  Consideration 
should  be  given  to  implementing  a  small  SPLICE  office 
system,  based  on  the  TANDEM  EXT  system  at  NAVSUP 
headquar ters ,  and  tied  into  SPLICENet  through  the  FDC 
facility  at  Chevy  Chase.  At  a  minimum,  NAVSUP  should 
have  a  facsimile  machine  available  at  headquarters  so 
that  hardcopy  output  can  be  received  by  NAVSUP. 

This  concludes  the  discussion  of  the  OA  application. 

Before  the  area  of  SPLICE  related  financial  applications 
is  addressed,  one  additional  comment  concerning  locally 
developed  applications  must  be  made.  It  is  extremely 
important  that  NAVSUP  functional  and  SPLICE  personnel 
monitor  the  local  applications  being  developed,  such  as 
those  described  above,  for  possible  implementation  stock 
point  wide.  From  the  authors'  review  of  preliminary 
documentation  on  such  systems,  it  is  also  imperative  that 
standards  for  local  system  documentation,  development, 
maintenance,  lead  CDA  responsibility,  and  most  importantly 
data  naming  standards  be  established  and  mandated  for  use  in 
these  locally  developed  systems. 


FINANCIAL/PROCURHMENT  APPLICATION  SUPPORT  THROUGH  SPLICE 


A.  CHAPTER  OVERVIEW 

This  chapter  will  address  selected  under  development, 
planned,  and  existing  applications  in  the  financial  services 
and  procurement/contracting  functional  areas,  as  well  as 
make  proposals  on  how  they  might  benefit  from  improved  use 
of  and  interfaces  with  SPLICE.  The  same  format  for 
applications  analysis  specified  at  the  beginning  of  Chapter 
IV  will  also  be  used  in  this  chapter. 

The  first  application  to  be  reviewed,  the  Automation 
of  Procurement  and  Accounting  Data  Entry  (APADE)  system,  is 
from  the  procurement/contracting  functional  area  of  UADPS- 
SP.  APAQE  is  currently  under  development  by  FMSO  for  use  on 
SPLICE  hardware.  The  method  to  be  used  in  analysis  here 
will  be  to  review  the  existing  development  plans  for  the 
application  and  make  r ec ommend a t  i  o n s  for  improved  use  of 
SPLICE  capabilities  where  appropriate. 

The  second  section  deals  with  a  project  that  promises 
an  all  new  financial  and  accounting  system  for  the  Navy.  It 
is  designated  the  Integrated  Disbursing  and  Accounting 
Financial  Information  Processing  System  ( IDAFIPS) .  The 
perspective  to  be  used  in  this  presentation  is  that  of  the 
developers  and  how  they  see  the  system  being  implemented. 

The  authors  will  then  make  r ec omm end  a t i o n s  on  how  this 


system  can  be  better  supported  by  using  SPLICE  in  its  system 
integration  and  telecommunications  support  capabilities. 

The  third  section  concerns  a  system  that  has  already 
been  implemented  at  tne  Navy  stock  points  as  a  forerunner  to 
IDAFIPS.  Tne  system  is  known  as  the  Integrated  Disbursing 
and  Accounting  DX  Phase  11(B)  E.  It  should  be  noted  that 
this  system,  part  of  the  original  FMSO  Financial  Management 
Improvement  Program  (FMIP)  at  the  stock  points,  will  be 
replaced  in  the  future  by  the  standardized  version  of 
IDAFIPS  which  is  under  development  by  the  Navy  Comptroller 
Standard  Systems  Activity  ( NAVCOMPTSSA )  . 

The  final  section  is  also  financial  in  nature,  but  is 
more  limited  in  scope  then  the  previous  three.  The  fourth 
section  addresses  the  Navy  Standard  Civilian  Payroll  System 
(NAVSCIPS)  that  is  also  being  developed  by  NAVCOMPTSSA.  In 
this  area,  following  a  discussion  of  major  functions,  the 
authors  have  made  recommendations  on  how  NAVSCIPS  might  be 
better  implemented  within  the  stock  point  community  by  using 
SPLICE  in  some  of  its  interface  and  data  entry  roles. 

With  this  plan  of  action  mind,  the  discussion  of  the 
APADE  application  can  be  undertaken. 

B.  AUTOMATION  OF  PROCUREMENT  AND  ACCOUNTING  DATA  ENTRY 

SYSTEM  (APADE) 

The  Navy  Supply  System  cannot  afford  to  stock  all  the 
repair  parts,  material,  and  services  that  are  required  for 
its  efficient  operation  or  to  meet  all  customer  demands.  It 
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is  often  necessary  to  procure  items  and  services  on  the  open 
market.  NAVSUP  has  been  designated  responsible  for 
administering  the  purchase/contract  functional  area  and  uses 
a  Navy  Field  Contracting  System  (NFCS)  to  perform  this 
function. 

Numerous  attempts  have  been  made,  both  centrally  from 
FM SO  and  at  local  activities,  to  automate  this  labor,  paper, 
and  time  consuming  function  using  a  variety  of  vendor 
hardware,  software,  and  applications.  [Ref.  69]  summaries 
many  of  these  efforts.  To  date,  none  of  these  efforts  have 
met  with  complete  success  and,  thus,  none  have  resulted  in 
system  wide  deployment  of  an  application.  Failure  to  make 
progress  in  this  area  has  resulted  in  much  of  the  continued 
criticism  of  the  entire  Navy  procurement  "system"  both 
externally  and  internally. 

From  the  second  "rising"  of  SPLICE  in  1979,  plans  have 
been  in  place  to  address  the  NFCS  support  area  via  hardware 
and  software  procured  by  the  SPLICE  project  and  application 
software  developed  by  FMSO.  Only  since  1984,  however,  has 
high  level  Navy  interest  to  do  this  become  evident  and 
commonplace,  apparently  resulting  from  the  Buy  Our  Spare 
Smart  (BOSS)  initiative  [Ref.  70].  The  new  APADE  system  is 
the  result  of  this  heightened  interest. 

Specifically,  APADE  will  provide  NFCS  activities  a 
standardized  ADP  hardware  and  software  system  which  can 
pro v id  e  : 


1.  document  control; 

2.  management  and  buyer  support  information; 

3.  automated  document  preparation; 

4.  and  stand-alone,  collocated  host,  and  satellite  ADP 
processing  support. 

The  underlying  concepts  being  used  by  APADE  to  implement 
these  capabilites  are:  1.  an  automated  " b  i  r t h- to-d e a t n" 
document  control  system;  2.  integration  of  data  and  word 
processing;  3.  single  source  data  automation  with  location 
independent  proc e s s - to- proc e s s  interaction;  and  4.  maximum 
use  of  interactive  processing. 

System  monitoring  within  APADE  will  begin  with  on-line 
requisition  input,  which  will  be  possible  both 
electronically  from  remote  systems  and  locally  from 
terminals  on  the  APADE  system  itself.  Monitoring,  tracking, 
and  automated  status  reporting  to  external  and  local  system 
users  then  is  possible  and  continues  through  the  entire 
technical  review  and  contracting  processes.  Assisted  by 
automated  support  tools,  APADE  users  can:  plan  procurements; 
prepare  so  1  i  c  i  t a t i o n s ,  purchase  orders,  contracts, 
amendments,  and  modifications  on  system  produced  standard 
government  forms;  and  interact  with  financial,  supply,  and 
adm i n i s tr a t i v e  processes  to  provide  updates  and  status.  An 
extensive  range  of  management  and  buyer  reports  are  planned 
for  automation  including  wo  r  k  -  i  n- pr  og  r  e  s  s  reports,  completed 
work  or  productivity  reports,  all  reports  required  by  law  or 
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regulation,  POA&Ms  for  individual  procurement  vehicles,  as 
well  as  an  ad  noc  reporting  capability. 

The  FMSO  APADE  functional  design  document  includes  seven 
processing  areas  to  perform  the  above  functions  which 
include,  requisition  input/update  processing,  pre-award 
processing,  award  processing,  contract  management 
processing,  inquiry  processing,  report  processing,  and 
system  management  processing.  See  [Ref.  71]  for  detailed 
specifications.  A  phased  implementation  approach,  including 
a  prototype  system,  will  be  utilized. 

The  benefits  which  can  accrue  to  NAVSUP  from  successful 
implementation  of  the  APADE  application  within  N F C S  include: 

1.  reduced  procurement  administration  lead  time  and 
actual  overall  procurement  time; 

2.  increased  information  accuracy  and  management  control; 

3.  increased  NFCS  worker  productivity; 

4.  and  improved  interfaces  with  other  systems. 

Several  aspects  of  plans  for  implementing  APADE  on 

SPLICE  are  worthy  of  note  in  terms  of  increased  corporate 
support  and  supporting  higher  level  NAVSUP  planning 
initiatives.  First,  APADE  intends  to  maximize  system 
integration  efforts  by  providing  on-line  interfaces  to 
systems  such  as  UADPS-SP,  the  Shipyard  Management 
Information  Sy s t em/ M a t er  i  al  Management  (SYMIS/MM),  the 
NAVAIR  Industrial  Management  System  (NIMMS),  the  IDA 
systems,  and  the  Engineering  Data  Management  Information  and 
Control  System  (EDMICS)  [Ref  72].  Electronic  requisition 


inputs  from  applicable  systems  are  necessary  to  reduce  the 
amount  of  re- keying  of  data  within  APADE  itself.  Electronic 
interface  to  EDMICS  appears  required  to  provide  buyers  the 
use  of  centralized  technical  data.  Automatic  electronic 
status,  reporting,  and  financial  transactions  from  APADE  to 
otner  applicaole  systems  also  appears  required  to  reduce 
buyer  time  lost  in  providing  manual  status  or  generating 
no n- pr oc ur em en t  related  transactions  to  these  foreign 
systems. 

Secondly,  APADE  plans  to  make  use  of  state  of  tne  art 
technology  for  system  user  input/output  devices.  PCs  are 
planned  for  use  as  multifunction  workstations.  These  PCs 
can  be  interfaced  to  the  SPLICE  TANDEM  hosts  as  TANDEM  6530 
terminals  either  through  TANDEM  provided  PC  LINK  software  or 
via  FDC  provided  third  party  TANDEM  terminal  emulation 
software.  In  terms  of  output,  laser  printers  will  be  used 
for  generation  of  contract  related  forms  and  high  speed  line 
and  remote  printers  for  management  reports.  No  plans  for 
support  of  card  input  or  output  are  evidenced. 

Finally,  APADE  appears  to  have  successfully  incorporated 
an  integrated  data  processing  and  word  processing  approach 
within  the  application.  Although  the  interface  details  are 
not  specified  in  the  documentation  reviewed,  the  same  APADE 
terminal  will  be  capable  of  using  TANDEM  data  processing 
facilities  under  P ATHWAY / ENCOMPASS  (e.g.,  for  inquiries,  Duy 


status  updates,  etc.)  and  the  TANDEM  PS  TEXT/T-TEXT/PS  TEXT 
FORMAT  word  processing  facilities  for  document  preparation. 

Having  described  its  purpose  and  potential  benefits  to 
tne  corporation,  the  APADE  application  can  be  now  analyzed 
in  terms  of  its  need  and  potential  for  migration  to  tne  SPmR 
Project.  In  that  APADE  will  be  totally  SPLICE  resident, 
there  appears  to  be  no  need  to  migrate  it  to  the  SPAR 
transition  environment.  A  transaction  and  process-to- 
process  interface  between  SPLICE  and  SPAR  will  be  required 
immediately  so  that  electronic  inputs  to  APADE  and  status 
from  APADE  can  be  forwarded  to/ from  transitioned  UADPS-SP  on 
SPAR  on-line.  However,  this  should  be  no  different  than 
that  required  in  SPLICE  ABE  or  for  SPLICE  terminal 
connec  t  iv  i  ty  . 

In  that  SPAR  will  eventually  replace  all  SPLICE 
a ppl  i c a t  i  on s ,  the  APADE  application  must  be  supported  under 
modernized  SPAR.  The  potential  for  moving  this  function  to 
SPAR  appears  good  in  light  of  increasing  emphasis  of  major 
hardware  m an u f ac t ur er s  to  provide  both  data  processing  and 
full  word  processing  capability  on  the  same  hosts.  However, 
in  that  the  TANDEM  data  and  word  processing  environments  are 
so  different  from  that  of  any  of  the  potential  SPAR  contract 
bidders,  a  complete  re-design  of  APADE  on  the  SPAR  hardware 
should  be  anticipated  at  the  end  of  its  life  on  TANDEM. 

The  final  area  that  will  be  addressed  is  how  APADE 
tactically  supports  or  can  be  made  to  better  support  the 


proposed  SPLICE  objectives,  thereby  supporting  previously 
presented  corporate  and  project  goals  and  strategies.  APADE 
directly  supports  and/or  is  supported  by  the  following 
SPLICE  project  objectives:  4,  5,  6,  7,  12,  13,  14,  15,  29, 
30,  31,  32,  33,  34,  35,  41. 

There  are  several  recommendations  the  authors  have  for 
possible  enhancements  to  APADE  on  SPLICE  that  will  enaole  it 
to  provide  greater  support  or  benefit  to  the  corporation: 

1.  Develop  an  APADE  Hardware  Interface  Requirements 

Spec i f ica  t ion) . 

a.  The  APADE  FD  indicates  several  on-line  interfaces 
to  SPLICE  that  SPLICE  does  not  currently  support 
or  for  which  SPLICE  has  been  unable  to  obtain 
approval.  These  include  Data  General  hardware  for 
EDMICS  support,  Honeywell  DPS-6  for  SYMiS/MM 
support,  and  Univac  1100  interface  for  Navy 
Laboratories  or  NIMMS  support. 

b.  Include  within  this  the  nature  of  the  connectivity 
required.  If  a  high  speed,  large  volume  data 
interface  to  a  collocated  processor  is  required 
(i.e.,  U  1 1 0 0 )  ,  that  may  be  easily  accommodated, 
assuming  that  the  host  concerned  has  a 
HYPERchannel  interface.  If  terminal  or  data 
communications  interface  is  required,  that 
represents  a  different  problem  and  must  be 
addressed  separately.  If  multiple  system  terminal 
access  is  required,  that  is  yet  another  problem. 

c.  Include  which  of  these  systems  does/will  support 
X.25  and  DDN.  Support  for  either  may  make  long 
haul  interface  requirements  simpler  to  satisfy. 

2.  Develop  an  APAOE  Software  Interface  Requirements 

Speci fication. 

a.  Assuming  the  issues  within  hardware  connectivity 
are  resolved,  the  application  level  interfaces 
among  these  systems  must  be  addressed  and 
specified.  Although  it  may  be  a  simple  matter  to 
forward  an  APADE  generated  status  transaction  to  a 
UADPS-SP  program  over  HYPERchannel,  there  may  be 
no  existing  application  on  a  DPS  6  running 


SYMIS/MM  expecting  an  external  system  generated 
data  communications  status  input,  for  example. 

b.  Include  complete  input  and  output  formats  for 
transactions  to  avoid  later  confusion,  if  other 
than  standard  MILSTRIP  formats  are  required,  as 
the  documentation  reviewed  indicates. 

Investigate  the  need  for  a  direct  APADE  to  EDMICS 
interface  and  perform  a  cost  and  feasibility  study 
prior  to  implementation. 

a.  Does  a  need  really  exist  for  buyers  to  see  EDMICS 
drawings  and  specifications  on-line  at  their 
terminals,  or  will  it  suffice  to  have  technical 
personnel  print  applicable  documents  on  their 
independent  EDMICS  terminal  printers  and  attacn 
them  to  the  hardcopy  procurement  request? 

b.  TANDEM  does  not  today  support  CAD/CAM/CAE  or 
graphics  applications  except  on  stand  alone  PCs. 
Unless  bit-mapped  graphics  streams  can  be  passed 
through  the  TANDEM  via  an  existing  protocol  or 
emulation  package  (i.e.,  SNAX,  TR3271,  EM3270, 
etc.),  through  an  application,  to  a  connected 
APADE  PC  workstation  with  graphics  capability, 
this  interface  may  not  be  possible. 

c.  Unless  the  EDMICS  system  is  a  planned  DDN  user, 
SPLICE  may  have  great  difficulty  getting  data 
communications  access  to  it. 

Investigate  the  use  of  TANDEM's  PC  LAN  interface 
capability  for  terminal  interconnection  at  all  sites, 
but  particularly  stand  alone  sites  such  as  Navy 
Regional  Contracting  Centers  (NRCCs).  In  that  APADE 
plans  to  use  PCs,  it  may  be  more  advantageous  to 
obtain  and  use  the  TANDEM  host/local  area  network 
interface  for  PCs  in  terms  of  cost,  speed, 
obtaining/install ing  data  communication  lines,  and 
original  equipment  manufacturer  support,  than  to  use 
PC  LINK/EM6530PC  or  third  party  TANDEM  terminal 
emulation  software  and  the  TANDEM  6100  communications 
subsystem. 

Require  the  implementation  of  DDA  at  stand  alone  APADE 
sites  for  transaction  and  status  passing,  along  with 
the  planned  DDN  interface.  DDA  is  currently  not 
sc  hed  u 1 ed  for  NRCCs  . 

Investigate  the  development  of  TANDEM  TRANSFER  or 
PS/MAIL  client  servers  to  distribute  reports  destined 


for  NAVSUP  or  other  SPLICE  sites.  Such  servers  can  oe 
easily  interfaced  to  PATHWAY  applications,  providing 
immediate  electronic,  paperless  report  distribution 
locally  or  over  SPLICE  Net. 

7.  Ensure  tne  APADE  data  naming  conventions  remain 
consistent  with  both  NAVSUP  508  [Ref.  73]  and  the 
emerging  SPAR  standards,  to  ease  later  transition. 

This  concludes  the  discussion  of  APADE.  IQAFIPS  will  be 
the  application  to  be  addressed. 


C.  INTEGRATED  DISBURSING  AND  ACCOUNTING  FINANCIAL 

INFORMATION  PROCESSING  SYSTEM 

The  Integrated  Disbursing  and  Accounting  Financial 

Information  Processing  System  (IDAFIPS)  is  designed  to 

streamline  and  automate  the  Navy’s  financial  management 

system.  The  purpose  of  IDAFIPS  is  to  provide  the  Navy  with: 

A  timely  and  accurate  performance  of  disbursing 
functions  and  the  updating  of  accounting  data  bases;  to 
interface  with  other  financial  and  supply  systems;  to 
generate  fiduciary  reports  and  provide  for  on-line 
inquiry  and  update;  to  validate  mechanically  input  data 
elements;  and  to  support  electronic  data  entry  at  field 
activities  and  the  financial  information  processing 
centers  (FIPCs).  [Ref.  74] 

The  system  is  comprised  of  five  subsystems,  which  are 
described  below. 

The  Integrated  Disbursing  and  Accounting  Financial 
Management  System  (IDAFMS)  is  the  primary  subsystem  within 
IDAFIPS.  The  main  purpose  of  IDAFMS  is  to  mechanically 
integrate  the  accounting  and  disbursing  modules  at  field 
level  activities  and  provide  a  standard  financial  management 
system.  This  system  will  also  fully  automate  the  bill 
paying  functions  for  the  Navy  at  the  field  level. 


More  specifically,  IOAFMS  operates  as  follows.  Invoices 
received  from  vendors  will  be  passed  through  a  mechanized 
payment  certification  process  and  be  validated  against 
procurement  documents  input  previously  by  the  fund 
adm  in  i  str ators  .  52  The  system  will  also  automatically  take 
discounts  and  certify  the  invoices  to  be  passed  to  the 
disbursement  module  for  check  generation  and  then  onto  a 
report  generation  module  for  the  necessary  record  updates. 

In  addition  to  handling  bill  payment  processing  via  check 
generation,  the  disbursing  module  also  will  take  care  of  all 
the  allotment  accounting  and  disbursing  for  field  level 
claimants  ashore  using  0&M,N,  0&M,NR,  and  RDT&E  dollars. 

IDAFMS  will  be  implemented  at  13  regional  sites,  called 
FIPCs,  using  a  real  time  access  data  base  system.  All  FIPCs 
should  be  collocated  with  SPLICE  computer  sites.  The  data 
base  at  each  FIPC  will  be  accessible  through  remote 
terminals  for  on-line  updates,  as  well  as  for  batch  updates 
and  report  transfers.  The  IDAFMS  data  base  will  provide 
sufficient  information  to  meet  all  the  required  financial 
management  needs  of  the  Fleet  Accounting  Activities  (FAA's) 
serviced  by  the  FIPC's  and  all  that  is  required  by  the  FIPC 
itself.  Over  900  FAAs  will  be  supported  by  the  FIPCs. 
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properly  designed  and  interfaced,  APADE  could 
provide  these  inputs  directly. 


In  s  ii  iTt  m  a  r  y  form,  I  D  A  F  M  S  will  use  modern 
t e 1 ec ommun i c a  :  i cn s  capaoilities  to  provide  Navy  management 
with  data  for: 

1.  planning,  programing,  and  budgeting  resources; 

2.  executing  against  budgeted  resources; 

3.  effective  control  over  all  assigned  funds  for  which 
the  Navy  is  responsible; 

4.  and  timely,  complete,  reliable,  and  accurate 
financial  reports  for  internal  Navy  management  use 
and  for  external  agencies  and  authorities  (e.g., 

0MB,  Congress,  Treasury,  DOD). 

IDAFMS  system  features  include: 

1.  random  access  data  base  processes  located  at  the 
reg ional  FIPCs  ; 

2.  extensive  internal  control  requirements; 

3.  use  of  telecommunications  to  support  interactive 
terminals  and  c ompu t e r- t o- c om p u t er  exchange  of  data; 

4.  and  interfaces  with  other  IDAFIPS  subsystems.  [Ref. 
75] 

The  telecommunications  interfaces  for  IDAFMS,  and  most 
of  IDAFIPS  for  that  matter,  will  be  locally  provided  by  the 
selected  hardware  manufacturer  and  eventually  by  DDN  for 
long  haul  communications.  In  the  interim  to  having  a  DDN 
capability  or  interface,  land  lines  will  be  used  for  long 
haul  communications. 

The  second  subsystem  of  IDAFIPS  is  called  IDAFMS 
OPFORCES,  and  will  be  the  standard  Navy  operating  forces 
accounting  system.  IDAFMS  OPFORCES  will  work  closely  with 
and  through  the  IDAFMS  module.  IDAFMS  will  take  care  of 
effecting  the  IDAFMS  OPFORCES  accounts  payable  transactions 


through  its  mechanized  bill  payment  certification  process 
and,  at  the  same  time,  report  to  the  Financial  Reporting 
System  (FRS)  module. 

IDAFMS  OPFORCES  is  to  provioe  the  following  specific 
features : 

1.  an  integrated  accounting  and  reporting  system  for 
deploying  and  shore  based  Operating  Target  (OPTAR) 
holders; 

2.  one-time  source  data  capture; 

3.  mechanized  interface  with  other  IDAFIPS  subsystems 
to  eliminate  hard  copy  generation; 

4.  a  standardized,  highly  responsive  financial 
management  system; 

5.  a  single  data  base  with  daily  updates  and  report 
generation  and  on-line  inquiry  capabilities; 

6.  interactive  edit  and  validation  at  source  of  input. 
[Ref.  76] 

The  telecommunications  interfaces  to  implement  the 
IDAFMS  OPFORCES  system  have  not  been  determined  at  this 
time.  Since  a  reduction  of  hardcopy  transmission  is  one  of 
the  major  driving  forces  behind  IDAFIPS,  an  afloat 
telecommunications  transfer  system,  as  described  in  Chapter 
VIII  of  this  thesis,  warrants  serious  consideration. 

The  Financial  Reporting  System  (FRS)  is  the  third 
subsystem  of  IDAFIPS  and  it,  too,  depends  very  heavily  on 
interfaces  with  IDAFMS.  FRS  will  provide  the  vehicle  to 
accumulate  and  prepare  for  transmission  of  financial  data 
between  FIPCs  and  from  each  FIPC  to  the  next  higher  level  of 
command  it  reports  to.  It  is  designed  to  operate  on  the 


IDAFMS  hardware  located  at  the  FIPCs  and  to  reduce  the  laoor 
intensive  functions  of  today's  system  through  on-line 
interactive  processing,  while  eliminating  some  batch 
processing  techniques.  FRS  is  to  provide  the  following: 

1.  reporting  at  the  Department  of  the  Navy  (DON)  level 
as  specified  by  N A V C 0 M P T ; 

2.  detail  expenditure  and  collection  data  for 
processing  by  the  Centralized  Expenditure/ 
Reimbursement  Processing  System; 

3.  reports  of  funds  expenditures  and  collections  at  the 
detail  transaction  level  to  Authorized  Accounting 

•  Activities  (AAAs); 

4.  automated  cashbook  processing  for  Disbursing 
Officers; 

5.  and  overseas  and  afloat  disbursing  officer 
reporting.  [Ref.  77] 

FRS  is  to  be  an  on-line  entity  that  will  increase  the 
timeliness  of  reports  and  provide  the  capability  for  higher 
commands  to  do  on-line  inquiry  of  specific  financial 
information  of  subordinate  commands.  It  will  also  reduce 
the  amount  of  hardcopy  reports  transmitted  between  commands 
through  use  of  an  IDAFIPS  telecommunication  network. 

The  final  subsystem  under  IDAFIPS  is  the  Claimant 
Accounting  Module  (CAM)  which  will  be  used  by  major 
claimants  to  process  and  summarize  accounting  data  received 
from  subordinate  commands,  via  the  IDAFMS  and  OPFORCES 
modules,  for  summarized  reporting  to  higher  authority. 

Major  claimants  using  the  IDAFIPS  data  base  will  be 
permitted  to  do  on-line  inquiry,  update  of  files,  and  report 
generation.  Each  claimant  will  be  supported  by  one  of  the 


thirteen  regional  FIPCs.  Since  many  of  the  major  claimants 
and  the  FIPCs  are  not  collocated,  claimant  interface  to  CAM 
will  be  via  telecommunications. 

In  order  to  provide  the  kind  of  service  that  is  to  be 
provided  by  IOAFMS  it  was  determined  that  a  stand-alone 
computer  system  for  each  FIPC  was  required.  A  dual 
configuration  of  Burroughs  B  6  9  0  0  s  was  selected  with 
associated  B1900  remote  batch  term inal / pr inter  and  tape 
drives  53  at  selected  sites.  [Ref.  77]  Now  that  a  computer 
system  has  been  procured,  the  keystone  to  making  the  IDAFMS 
system  work,  once  the  applications  are  developed,  will  be 
the  telecommunications  system. 

Since  nearly  all  of  the  reporting  of  financial 
information  in  the  past  has  been  by  hard  copy  or  magnetic 
tapes  and  these  methods  were  determined  to  be  inadequate  to 
implement  the  IDAFIPS  system,  a  large  telecommunications 
system  has  been  called  for  in  all  the  system  documentation. 
Unfortunately,  beyond  statements  that  DDN  will  be  used  in 
the  long  run  for  long  haul  communications  and  Burroughs 
Network  Architecture  (BNA)  will  be  used  in  the  short  run, 
the  details  as  to  what  will  comprise  this  IDAFIPS 
telecommunications  network  and  how  it  will  be  implemented 
were  not  available  at  the  time  this  research  was  being  done 
In  light  of  this,  the  authors  would  like  to  explore  ways  in 

5 3 1 1  should  be  noted  that  the  BI  900  is  one  of  the 
systems  that  NAVSUP  was  eliminating  at  the  stock  points 
through  SPLICE. 


which  SPLICE  could  provide  some  portion  of  the 
telecommunications  support  required  to  handle  the  snaring  of 
financial  information  at  the  stock  points  and  for  afloat 
units,  as  called  for  by  IDAFIPS. 

In  the  13  regional  areas  where  the  B  6 9 0  0 ' s  will  be 
located  there  will  also  be  a  SPLICE  site  in  the  same 
vicinity,  if  not  in  the  same  computer  room.  Since  the 
majority  of  the  86900‘s  will  be  located  at  SPLICE  sites 
(i.e.,  NSCs  who  are  FIPCs  or  NARDACs,  which  may  operate  the 
IDAFMS  hardware) ,  it  is  feasible  that  the  SPLICE  system 
could  perform  the  following  functions  at  IDAFIPS  sites: 

1.  passing  bulk  files  and  individual  transactions  from 
UADPS-SP/ SPLICE  to  the  IDAFIPS  66900s  through  use  of 
the  SPLICE  HYPERchannel  network.  Financial 
information  to  be  passed  would  include  that  which  is 
produced  as  material  is  purchased  (i.e.,  from  APADE  on 
SPLICE),  is  received  (i.e.,  from  ABE  on  SPLICE),  and 
is  requisitioned  from  the  stock  points  (i.e.,  from 
End-of-Day  processing  or  applications  E  &  F).  Using 
such  a  facility,  the  SPLICE  system  would  also  be  able 
to  accumulate  financial  files  or  data  to  be  added 
eventually  to  the  IDAFMS  data  base,  in  an  off-line 
mode  (i.e.,  on  a  contingency  basis  when  the  Burroughs 
6900s  suffer  hardware  or  telecommunications  problems) 
and  forward  it  to  tne  Burroughs  6900s  to  be  processed 
at  a  later  time. 

2.  a  gateway  for  the  8  6  9  0  0  *  s  to  the  DDN  and  thus  to  other 
FIPCs  and  SPLICE  sites  around  the  country.  This  would 
release  the  86900's  from  having  to  use  capacity  or  a 
unique  FEP  to  accommodate  a  separate  DDN  interface  and 
would  reduce  Navy  host  access  charges  at  processing 

s i tes  .  54 

3.  a  FEP  for  Burroughs  terminals  requiring  access  to  both 
U ADP S- SP  /  SPL I CE  applications  and  the  IDAFMS  modules  at 
stock  points.  Using  the  SPLICE  Burroughs  terminal 


54current  cost  estimates  for  a  host  connection  to  DDN 
range  between  $2000  to  $5000  per  host  per  month  [Ref.  78]. 


support  capability,  a  single  terminal  on  SPLICE  in  tne 
hands  of  an  authorized  user  could  be  made  to  have  pass 
through  capability  to  eitner  the  UADPS-SP  or  IDAFMS 
Burroughs  systems  by  use  of  the  Burroughs  Pre- 
Processor  Module  to  UADPS-SP  and  a  similar  module  to 
be  developed  to  link  to  IDAFIPS. 

4.  a  connection  point  for  local  non-Burrougns  terminals 
and  users  that  are  outside  the  immediate  FIPC  and  that 
require  (and  are  authorized)  access  to  the  IDAFMS  data 
base.  By  providing  this  service,  SPLICE  could  reduce 
terminal  procurement  costs  and  data  communications 
line  costs,  while  relieving  the  Burroughs  IDAFMS 
system  from  having  to  handle  some  of  its 
telecommunications  overhead. 

5.  an  alternative  to  procuring  Burroughs  B1900  RJE 
computers,  particularly  where  these  may  have  been 
planned  for  sites  already  designated  as  SPLICE  MAPS 
RJE  f ac i 1 i t  i  es  . 

6.  the  interface  between  NAVSCIPS  and  IDAFMS,  eliminating 
the  need  to  pass  tapes  between  the  systems. 

7.  the  ICP  interface  to  IDAFMS,  using  the  SPLICE  sites  at 
these  activities  and  SPL I CENe t / DDN  to  pass  data  to  the 
SPLICE  site  collocated  with  the  regional  IDAFMS  nost. 

8.  the  OPFORCES  interface  to  IDAFMS,  using  the  interface 
methods  proposed  in  Chapter  VIII. 

9.  the  NIMMS  U1100  application  interface  to  IDAFMS,  if 
and  when  the  U1100  HYPERchannel  interface  is 
authorized . 

The  benefits  that  such  interfaces  would  have  to  the 
corporation  and  the  Navy  at  large  are  primarily  financial: 
reduced  telecommunications  line  and  DDN  host  connection 
costs;  reduced  terminal  procurement  costs;  and  reduced  tape 
handling  and  manual  intervention  costs.  Additionally,  space 
savings  could  accrue,  in  that  single  terminals  at  sites 
would  be  able  to  function  in  multiple  processing 
environments.  Finally,  a  means  to  accomplish  an  afloat  unit 


interface  is  provided,  which  appeared  lacking  or  at  least 
undefined,  in  the  documentation  reviewed. 

The  final  area  that  will  oe  addressed  is  how  IDAFIPS  ana 
tne  proposed  SPLICE  objectives  can  be  mutually  supportive, 
tnerepy  supporting  previously  presented  corporate  ana 
project  goals  and  strategies.  The  IDAFIPS  efforts  directly 
support  and /or  are  supported  by  the  following  SPLICE  project 
objectives:  12,  15,  16,  19,  22,  25,  27,  and  34. 

Since  tne  interfaces  proposed  here  between  IDAFIPS  and 
SPLICE  do  not  currently  exist,  there  is  currently  no  way  to 
migrate  them  to  SPAR.  However,  unless  the  Navy  wishes  to 
continue  with  the  awkward  and  antiquated  tape  passing  of 
financial  data,  some  methods  such  as  those  proposed  above 
should  be  adopted  to  interface  these  systems.  Whatever 
these  methods  are,  they  should  then  be  carried  forward  to 
the  SPAR  modernization  environment. 

There  are  several  recommendations  the  authors  have  for 
possible  enhancements  to  IDAFIPS  through  interfaces  to 
SPLICE  that  will  enable  them  both  to  provide  greater  support 
and  benefit  to  the  corporation.  These  are: 

1.  Investigate  the  use  of  the  SP L I CE N e t / DD N  as  a  primary 
means  of  transferring  data  and  communicating  between 
FIPCS,  instead  of  separate  IDAFIPS  host  DDN 
interfaces. 

2.  Investigate  the  use  of  the  HYPERc hannel s  to  link  the 
B 6 9 0 0 ' s  installed  at  the  FIPCS  with:  the  current 
Burroughs  and  SPLICE  systems  installed  at  the  NSC's; 
the  Burroughs,  SPLICE,  and  Univac  systems  at  the 
NARDACs;  and  the  IBM/SPLICE  connection  at  the  ICPs  to 
handle  the  transfer  of  the  required  financial 
information. 


3. 


Investigate  the  use  of  SPLICE  to  provide  the 
terminal  connection  for  terminals  requiring  access  to 
both  Burroughs  systems  resident  at  the  stock  points 
and  FIPCs,  as  well  as  utilize  non-Burroughs  terminals, 
and  to  provide  for  shipboard  access  to  FIPCs  as 
outlined  in  Chapter  VIII. 

This  concludes  the  discussion  of  IDAFIPS.  The  next  area 
to  be  discussed  is  IOA  11(B)  E. 

D.  INTEGRATED  DISBURSING  AND  ACCOUNTING  DX  PHASE  11(B)  E 

The  IDAFIPS  system  discussed  above  is  the  long  range 
plan  for  financial  management  in  the  Navy.  Prior  to 
IDAFIPS,  NAVCOMPT  had  sponsored  several  prototype  financial 
and  accounting  systems.  One  of  these  systems  was  developed 
by  FMSO  and  deployed  at  various  NAVSUP  organizations, 
including  the  major  stock  points,  under  the  banner  of  FMIP. 
Although  deployed  at  these  activities,  the  FMSO  FMIP  systems 
will  be  phased  out  under  the  IDAFIPS  system.  The  exact 
timing  of  this  phase  out  at  the  Navy  stock  points  is 
uncertain,  however,  and  until  that  time  the  FMSO  developed 
FMIP  modules  must  be  supported.  [Ref.  79] 

One  of  the  modules  of  FMSO  FMIP  is  the  Integrated 
Disbursing  and  Accounting  Data  Exchange  Phase  1 1 ( B ) E 
(IDA  II(B)E).  IDA  1 1 ( B ) E  is  of  particular  interest  to  this 
work  in  that  it  is  a  transition  candidate  to  SPLICE.  As 
such,  it  must  be  carefully  moved  to  the  SPLICE  hardware  and 
interfaced  to  other  stock  point  processes  in  the  most 
efficient  and  effective  manner  possible. 
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Tne  goal  of  the  entire  FMSO  IDA  program  was  to 
substantially  reduce  the  time  it  takes  to  input,  process, 
and  output  financial  data  at  the  stock  points  and  through 
tne  entire  disbursing  and  accounting  systems.  The  phases  of 
IDA  previous  to  1 1  ( 3 ) E  accomplished  such  things  as 
redirecting  the  flow  of  hard  copy  source  documents  from  the 
Navy  Regional  Finance  Center  to  the  local  AAA  s  ,  5 5 
innovations  to  processes  that  controlled  payments  of  vendor 
bills  and  reimbursable  billings,  and  improving  check  issue 
capabilities  with  mechanization  of  associated  reports.  All 
of  these  improvements  were  accomplished  on  the  Burroughs 
mainframes  and  primarily  in  batch  mode. 

The  batch  orientation  of  the  Burroughs  hosts  precluded 
any  additional  efforts  at  permitting  on-line  user  access  to 
the  various  accounting  and  disbursing  files.  However,  to 
achieve  its  goal  of  timeliness  in  financial  processing,  IDA 
had  to  provide  for  on-line  and  interactive  access  to  some  of 
its  files.  Therefore,  it  was  necessary  to  off-load  many  of 
the  o n- 1 i n e/ i n ter ac t i v e  processes  to  another  host.  In  the 
absence  of  SPLICE,  PE  hardware  and  TAPS  software  were  used. 

S^An  AAA  (pronounced  as  "triple  A")  performs  official 
accounting  and  disbursing  functions  for  multiple  commands 
within  an  area,  mostly  due  to  the  fact  that  AAAs  have  ADP 
systems  available  to  them.  The  area  commands,  usually 
referred  to  as  Funds  Accounting  Activities  (FAAs),  retain 
the  legal  responsibility  for  their  usage  of  their  funds, 
with  the  AAA  recording  the  results  of  FAA  actions  and 
processing  payments  which  result  from  those  actions. 


The  IDA  I  I ( B ) E  subsystem  focused  its  empnasis  on 
accounting  processes  at  the  AAAs  and  large  FAAs.  In  this 
phase,  selected  accounting  master  files  and  transactions 
were  to  be  extracted  from  the  Burroughs  hosts  and  made 
resident  on  PE  hardware  using  TAPS.  These  files  and 
transactions  were  then  to  be  accessible  by  AAA  and  selectea 
FAA  personnel  for  immediate  update,  inquiry,  and  on-line 
error  correction.  Changes  made  to  the  off-loaded  files 
would  be  applied  to  the  Burroughs  master  files  on  a  nightly 
basis,  through  PE  file  extracts  and  batch  updating  on  the 
Burroughs  system.  Following  completion  of  all  other  batch 
financial  processing,  selected  Burroughs  master  financial 
file  updates  would  then  be  applied  to  the  downloaded  files 
on  the  PE  for  further  processing,  again  via  tape  extracts. 

Once  the  files  were  loaded  and  PE  application  systems 
written  in  TAPS/COBOL,  the  key  to  this  phase  was  providing 
on-line  PE  system  access  via  available  Burroughs  terminals. 
More  specifically,  through  the  use  of  a  FMSO  developed 
terminal  access  and  networking  package  (i.e.,  INS),  users 
with  Burroughs  terminals,  who  in  the  past  would  have 
prepared  financial  input  documents  for  key  punching  and 
batch  processing  in  Application  G^6  on  the  Burroughs  could 
input  these  on-line  on  the  PE. 

^Application  q  is  the  Cost,  Allotment,  and 
A p pro pr i a t i on  Accounting  application  in  UADPS-SP. 


The  users  provided  such  access  were  at  Doth  the  AAAs  and 
selected  FAAs. 57  At  the  AAAs,  the  system  users  hac  the 
capability  to  input  and  correct  financial  transactions  for 
their  activities  ana  in  behalf  of  those  activities  not 
receiving  remote  terminals  in  an  on-line  mode.  The  FAAs 
could  only  access  their  own  files.  Other  normal  Application 
G  batch  UADPS  transactions  still  had  to  be  processed  on  a 
periodic  batch  basis  on  the  Burroughs. 58 

The  impact  of  this  system  is  that  for  the  first  time  the 
AAAs  and  FAAs  had  direct  access  to  the  accounting  files, 
giving  them  timely  accounting  and  financial  information. 
Additionally,  the  individuals  who  were  responsible  for 
transactions  could  input  them  themselves,  thereby  allowing 
immediate  error  correction  and  saving  the  time  required  for 
card  preparation  and  waiting  for  the  next  batch  process. 

The  Application  G  files  to  be  extracted,  downloaded,  and 
updated  by  the  transactions  entered  on-line  on  the  PEs  were 
the  Transaction/Exception  File,  Job  Order  Reference  File, 
Document  Control  File  (DCF),  Posting  File,  and  General 
Ledger  File.  [Ref.  80]  Outputs  from  Applications  E / F 5 9 

5?The  criteria  for  determining  which  FAAs  received 
terminal  hardware  was  existence  of  sufficient  transaction 
volumes  to  justify  the  costs  of  terminals  and  printers. 

^Application  G  type  updates  and  corrections  are 
normally  card  generated  and  run  in  batch  mode  on  the  late 
shift  about  three  times  a  week. 

5 ^ A p p 1 i c a t i o n  E  is  Financial  Inventory  Control  and 
Application  F  is  Stores  Accounting. 


could  be  also  be  input  directly  into  the  DCF  processes  being 
executed  on  the  PEs.  Transactions  to  these  files  could  be 
recalled  and  corrected  by  the  operators  of  the  terminals 
anytime  during  the  day. 

Where  then  does  SPLICE  fit  into  IDA  1 1  ( B ) E  ?  Following 
stock  point  wide  implementation  of  the  system,  capacity, 
response  time,  and  hardware  problems  plagued  the  PE  and  TAPS 
based  systems.  Once  users  became  dependent  on  the  system, 
these  problems  were  unacceptable,  and  in  the  case  of  late 
vendor  payments,  costly  in  terms  of  missed  discounts  and 
interest  or  penalty  payments.  Although  optimization  efforts 
were  continually  undertaken  by  FMSO  personnel  to  improve 
performance,  three  inescapable  facts  remained:  the  PE 
systems  had  no  backup;  they  could  not  share  resources  in  the 
event  of  minor  failures,  and  there  was  limited  surge, 
reserve,  or  expansion  capability.  SPLICE,  then,  was  to 
resolve  these  problems. 

As  was  mentioned  in  Chapter  IV  concerning  NAVADS,  the 
transition  strategy  from  PE  IDA  II(B)E  to  SPLICE  IDA  1 1  ( B )  E 
is  to  keep  the  transition  as  transparent  as  possible  to  the 
application  by  porting  TAPS,  in  its  updated  TAPS  II  PASCAL 
form,  to  the  SPLICE  TANDEM  system.  Transition  to  SPLICE 
should  only  require  current  TAPS  screens  to  be  r e  im pi em en t ed 
in  TAPS  II,  files  moved  to  TANDEM  ENSCRIBE  format  and 
interfaced  to  TAPS  II,  programs  re-compiled  into  TANDEM 
COBOL  and  interfaced  to  TAPS  II,  and  terminal  device  and 


security  functions  placed  under  the  control  of  the  FDC's 
SAS/TMAP  processes. 

As  was  also  previously  indicated,  the  performance  of 
TAPS  II  on  TANDEM  is  poor  today,  and  there  are  questions  as 
whether  sufficient  optimizations  can  be  made  to  make  it 
usable  in  a  production  environment.  The  alternative, 
however,  would  be  a  complete  re-design  of  the  current  system 
into  the  TANDEM  native  mode  TPS  using  PATHWAY  and  ENCOMPASS, 
prior  to  any  usage  on  SPLICE.  Economic  justification  of 
this  alternative  would  be  difficult  and  would  require 
continued  PE  and  TAPS  support  during  the  duration. 

The  transition  of  PE  IDA  1 1 { B ) E  to  SPLICE  will  provide 
the  corporation  three  of  the  four  benefits  that  PE  NAVADS 
transition  to  SPLICE  did:  a  reduction  in  non-SPLICE 
minicomputer  system  support;  non-stop  support  for  the 
accounting  function;  and  a  reserve,  expansion,  and  growth 
capability  for  the  application.  See  the  NAVADS  benefits 
paragraphs  in  Chapter  IV  for  further  elaboration  on  these 
points. 

Assuming  the  transition  of  IDA  1 1 ( B ) E  to  SPLICE,  there 
is  no  need  for  migration  of  IDA  1 1  ( B ) E  to  the  SPAR 
transition  environment.  The  SPLICE  terminal  and  process-to- 
process  interfaces  to  SPAR  will,  however,  also  be  required 
to  interface  to  the  other  host  Application  G  processes  that 
will  be  transitioned  in  their  current  form  to  the  new 
hardware.  When  SPLICE  is  replaced  by  modernized  SPAR,  the 


SPLICE  portion  of  IDA  1 1 ( B ) E  should  not  require  migration, 
in  that  IDAFMS  should  be  implemented  at  the  stock  points  by 
that  time . 

The  final  area  that  will  be  addressed  is  how  IDA  1 1  ( B  J  E 
tactically  supports  or  can  be  made  to  better  support  the 
proposed  SPLICE  objectives,  thereby  supporting  previously 
presented  corporate  and  project  goals  and  strategies.  IDA 
1 1 ( B ) E  directly  supports  and/or  is  supported  by  the 
following  SPLICE  project  objectives:  12,  15,  16,  19,  22,  25, 
27 ,  and  34. 

The  following  recommend ations  should  be  evaluated  by  the 
IDA  1 1 ( B ) E  and  SPLICE  projects  to  assist  in  the  further 
attainment  of  corporate  and  project  goals  and  objectives: 

1.  When  IDA  1 1 ( B ) E  is  implemented  on  SPLICE,  replace  the 
current  tape  file  uploads  and  downloads  with  a 
HYPERchannel  bulk  file  transfer  interface. 

2.  Ensure  that  SPLICE  IDA  users  are  afforded  Burroughs 
Pr e- P r oc e s so r  access,  to  enable  them  to  use  other 
Application  G  Burroughs  screens  updates  and  inquiries 
from  their  SPLICE  based  terminals. 

3.  Investigate  the  use  of  SPLICE  to  provide  the  other 
FAAs  IDA  1 1 ( B ) E  access  through  use  of  dial-in  lines 
and  intelligent  terminals/PCs  using  a  TANDEM  or 
Burroughs  terminal  emulation  package. 

4.  When  economically  justified,  replace  the  less 
functionally  capable  Burroughs  terminals  with  either 
TANDEM  or  IBM  3270  series  terminals. 

5.  Investigate  the  distribution  of  IDA  1 1  ( B ) E  local 
management  reports  via  TANDEM  TRANSFER  or  PS  Mail, 
thus  reducing  hardcopy  and  paper  r equ i r em en t s . 

6.  Develop  a  plan  to  transition  the  IDA  1 1  ( B )  E 
application  off  TAPS  II  entirely  to  native  mode  TANDEM 
PATHWAY/ENCOMPASS. 


7.  If  additional  Burroughs  capacity  relief  or  downloads 
are  desirable,  investigate  the  download  of  IDA  1 1 A  to 
SPLICE.  There  appears  nothing  in  this  subsystem  which 
mandates  its  processing  on  the  Burroughs.  If 
accomplished,  this  would  return  capacity  to  the 
Burroughs,  improve  the  stock  point  check  issue  and 
disbursing  reports  facilities,  is  a  natural  co¬ 
process  to  the  SPLICE  APADE  application  for 
procurement  initiation  and  SPLICE  ABE  for  receipts, 
and  will  reduce  SPAR  transition  r equ  i  r em en t s  . 

8.  If  it  appears  that  the  IDAFIPS  implementations  at  the 
stock  points  will  be  further  delayed,  investigate 
interim  interfaces  between  FMSO  IDA  (  i .  e .  ,  Burroughs 
and  SPLICE  resident)  and  IDAFIPS  using  SPLICE  systems 
as  the  gateway  for  terminals,  processes,  and  file 
transmissions. 

This  concludes  the  discussion  on  IDA  1 1  ( B ) E  .  The 
NAVSCIPS  interface  will  next  be  addressed. 


E.  NAVY  STANDARD  CIVILIAN  PAYROLL  SYSTEM  (NAVSCIPS) 

The  NAVSCIPS  is  to  be  the  standard  DON  payroll 
processing  system.  The  Navy  currently  has  seven  "standard" 
and  four  unique  systems  to  pay  civilian  employees,  emanating 
from  multiple  CDAs  and  local  activities.  The  Navy  is  the 
only  service  that  has  not  implemented  a  single  ;tandard 
payroll  system  and  to  correct  this  shortcoming,  NAVCOMPT  nas 
chosen  NAVCOMPTSSA  as  the  CDA  to  develop  NAVSCIPS  and 
directed  that  it  be  implemented  Navy  wide. 

NAVSCIPS  is  to  be  located  and  operated  at  designated 
FIPCs  and  Financial  Processing  Centers  (FPCs),  many  of  which 
will  be  collocated  with  SPLICE  sites.  NAVSCIPS  must 
interface  with  other  existing  systems  as  well  at  these  and 
other  remote  sites.  The  need  for  existing  system  interfaces 
stems  from  a  nebulous  requirement  for  major  claimants  to 


develop  "interface  programs  required  to  provide  standard 
inputs  and  process  standard  NAVSCIPS  outputs"  [Ref.  81].  6  0 
The  following  other  Navy  information  systems  are 
specifically  designated  as  requiring  a  NAVSCIPS  interface: 

1.  IDAFMS 

2.  SYMIS 

3.  Standard  Automated  Financial  System  (STAFS) 

4.  Naval  Ordnance  Management  Information  System  (NOMIS) 

5.  NAVAIR  Industrial  Financial  Management  System 
•  (NIFMS) 

6.  Navy  Civilian  Personnel  Data  System  (NCPDS)  [Ref. 

82] 

It  should  be  noted  that  no  NAVSUP  system  interface  is  called 
for,  leaving  both  the  NAVSUP  T/A  source  data  capture 
requirement  and  the  NAVSCIPS  output  to  NAVSUP  input  process 
problems  unaddressed. 

Having  received  T/A  inputs  from  these  other'  systems, 
NAVSCIPS  will  provide  standard  and  enhanced  pay  processing 
features  and  capabilities  such  as: 

1.  complete  validation  of  T/A  and  record  maintenance 
inputs; 

2.  identification  of  missing  T/A  records  for  a  period; 

3.  automated  pay,  leave,  and  time  history  records; 

4.  automated  retroactive  pay  and  leave  processing; 

5.  an  automated  document  control  system; 


60The  best  information  that  the  authors  could  obtain 
indicates  that  the  inputs  are  T/A  data  from  other  system 
mechanized  processes  or  source  data  automation  efforts. 


6.  automated  maintenance  of  the  SF  2806  Retirement 
Record; 

7.  standard  interfaces  with  financial  management 
information  systems  and  the  NCPDS; 

8.  some  reconciliation  of  pay  to  labor  data; 

9.  automated  management  reports  on  overtime  and  leave 
usage ; 

10.  and  a  report  generator  capability.  [Ref.  83] 

The  Navy  chose  a  PE  3210  system  as  its  standard  nardware 
suite  for  NAVSCIPS,  obtained  from  the  Navy  Minicomputer 
Contract  with  C3,  Inc.  NAVCOMPTSSA  sizing  efforts  have 
indicated  that  a  larger  computer  than  the  PE  3210  will  be 
required  for  NAVSCIPS  at  (at  least)  five  of  the  required 
implementation  sites.  No  indication  of  how  these  larger 
systems  will  be  procured  has  been  provided.  The  main 
applications  programs  supporting  NAVSCIPS  will  written  in 
COBOL  or  FORTRAN,  using  the  SEED  data  base  management  system 
and  supporting  development  tools.  [Ref.  84] 

The  foreign  system  interfaces  to  NAVSCIPS,  both  in  terms 
of  input  and  output,  are  loosely  stated  by  the  CDA  to  be 
magnetic  tape  and  hardcopy  or  computer  formatted  reports. 
Within  NAVSCIPS  itself,  terminal  entry  will  be  the  major 
source  of  input,  with  terminals  connected  to  the  NAVSCIPS  PE 
directly. 

There  are  three  areas  where  the  integration  of  NAVSCIPS 
and  SPLICE  at  the  stock  points  sites  could  be  of  benefit  to 
the  corporation.  First  using  the  NSC  Norfolk  local  SPLICE 
PPS  discussed  in  Chapter  V,  SPLICE  could  develop  a  standard 


T/A  input  process  to  NAVSCIPS  for  use  at  all  stock  points. 
This  would  eliminate  the  need  for  multiple  local  uniques  to 
accomplish  the  same  task.  At  the  same  time,  this  could 
eliminate  some  keypunching  and  card-to-disk  processing 
required  today  for  payroll  processing,  if  such  an  approach 
were  tied  to  the  stock  point  SPLICE  interim  office 
automation  efforts. 61 

Secondly,  a  PE  HYPERchannel  interface  could  be  used  to 
provide  interface  among  NAVSCIPS  PEs  and  several  of  the 
required  foreign  interface  systems,  including  SPLICE.  This 
high  speed  data/computer  interface  could  be  used  in  lieu  of 
tape  file  transfers,  could  permit  SPLICE  terminals  to  access 
NAVSCIPS  processes  without  the  need  to  procure  additional 
terminals,  and  permit  the  transfer  of  NAVSCIPS  output 
products  directly  to  other  systems  without  the  need  for 
hardcopy  document  preparation.  Such  an  approach  would 
reduce  land  line  telecommunications  costs,  terminal 
procurement  costs,  and  manual  output  handling  costs. 

Thirdly,  the  NSC  Norfolk  EFT  process  could  be  adopted, 
documented,  and  used  as  a  Navy  standard  civilian  payroll 
interface  to  the  Federal  Reserve  System.  Selected  SPLICE 
sites  could  be  used  as  gateways  to  the  FRBs  for  all  of 

6 1 1 n  this  scenario,  the  authors  envision  local  stock 
point  division  administrative  personnel  inputting  T/A  data 
received  from  stock  point  employees  directly  on  SPLICE 
terminals  on  a  daily  basis.  Following  supervisor  on-line 
approval,  site  consolidation  and  forwarding  of  T/A  data  to 
the  NAVSCIPS  system  would  be  undertaken  on  whatever 
periodicity  is  required. 


NAVSCIPS,  eliminating  need  for  each  NAVSCIPS  user  to  develop 
its  own  interface  or  use  manual  tape  handling  to  accomplish 
EFT  interface  r equ i r em en t s  . 

The  next  area  to  be  addressed  is  the  NAVSCIPS  need  for 
migration  to  the  SPAR  environment.  NAVSCIPS  can  be  seen  as 
outside  the  sphere  of  SPAR  transition  and  modernization. 
Therefore,  SPAR  migration  would  be  a  non-issue.  However, 
the  source  data  input  requirements  to  NAVSCIPS  and  output 
product  integration  requirements  into  other  stock  point 
processes  are  real  issues.  SPLICE  can  accommodate  these 
requirements  during  the  SPAR  transition  phase.  SPAR  itself 
will  have  to  address  these  requirements  in  its  mod er n  i  za t  i  o n 
phase. 

The  final  area  that  will  be  addressed  is  how  a  NAVSCIPS 
and  SPLICE  integration  effort  would  tactically  support  the 
NAVSCIPS  project  and  proposed  SPLICE  objectives,  thereby 
supporting  previously  presented  corporate  and  project  goals 
and  strategies.  The  NAVSCIPS-SPLICE  interface  directly 
supports  and/or  is  supported  by  the  following  SPLICE  project 
objectives:  12,  15,  19,  21,  22,  27,  and  34. 

The  following  recommendations  should  be  evaluated  by  the 
NAVSCIPS  and  SPLICE  projects  to  assist  in  the  further 
attainment  of  Navy  cor pora te/ proj ec t  goals  and  objectives: 

1.  Task  SPLICE  to  provide  a  standard  stock  point 
payroll  T/A  input  data  application  for  the  NAVSCIPS 
PE  systems. 

2.  Investigate  the  use  of  SPLICE  to  perform  the  EFT 
service  to  the  FR8s  as  a  standard  output  process 


from  NAVSCIPS.  SPLICENet  could  also  be  used  to 
assist  in  distributing  EFT  inputs  to  SPLICE  sites 
which  would  perform  a  gateway  service  to  FRBs. 

3.  Investigate  the  use  of  the  SPLICE  HYPERchannel  as  an 
interface  to  NAVSCIPS  to  permit  on-line  input  passing, 
sharing  of  terminals,  and  output  report  distribution. 

4.  Investigate  the  use  of  SPLICE  as  an  alternate 
NAVSCIPS  hardware  suite,  for  sites  where  the  PE 
systems  are  anticipated  to  have  capacity  problems. 

This  recommendation  is  contingent  on  the  ability  of 
the  SEED  DBMS  products  being  implemented  on  SPLICE, 
in  a  manner  similar  to  the  way  TAPS  II  was 
transitioned  on  SPLICE. 

5.  In  the  event  that  recommendation  number  4  is  not 
feasible,  expedite  the  movement  of  NAVADS  and  IDA 

1 1 ( B ) E  to  SPLICE  hardware  and  excess  the  larger  NAVSUP 
PE  systems  currently  used  by  these  applications  to 
NAVCOMPT  for  use  by  NAVSCIPS. 

This  concludes  the  discussion  of  NAVSCIPS  and  this 
section  on  financial  and  pr oc ur em en t / c o n tr ac t i ng  systems. 
SPLICE  shorebased  i n te ro per ab  i  1  i  ty  is  the  next  area  that 
will  be  considered . 


VII.  SHORE  BASED  INTEROPERABILITY 


A.  CHAPTER  OVERVIEW 

For  the  purposes  of  tnis  Jocusient,  interoperability  is 
defined  as  the  ability  of  multi-vendor  ADP  Hardware  and 
software  systems  or  components  to  communicate  [Ref.  85]. 
Witnin  the  000,  interoperability  is  mandated  due  to  a 
diversity  of  vendor  products  used  by  DOD  which  must  be 
i n ter f ac ed . 62  This  chapter  will  address  how  SPLICE  assists 
NAVSUP  is  meeting  its  r eq u i r em e n t s  to  support 
i n tero per ab i 1 i ty  in  three  areas:  terminal  connections, 
intra-site  connections,  and  inter-site  connections. 

B.  TERMINAL  CONNECTIVITY 

For  the  first  decade  that  UADPS-SP  resided  on  Burroughs 
hosts,  terminal  (i.e.,  CRTs  and  printers)  connectivity  nad 
not  been  an  issue:  no  Burroughs  terminal  meant  no 
connectivity  to  the  Burroughs  systems.  This  was  primarily 
due  to  three  things:  Navy  use  of  the  Burroughs  Poll/Select 
protocol  and  data  formats;  ease  of  obtaining  Burroughs 
terminals  off  existing  Nav y- B ur r o ug h s  contracts;  and  the 
inability  or  lack  of  desire  of  third  party  vendors  to 
produce  competitively  priced  Burroughs  compatible  terminals 


6  2  t  h  i  s  diversity  of  products  within  the  logistics 
community  is  due  primarily  to  ADP  open  market  competition 
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As  NAVSUP  began  its  move  into  a  CRT/remote  printer 
oriented  environment  at  the  stock  points,  particularly  on  PE 
minicomputers,  and  pressures  for  competitive  procurements 
mounted,  additional  sources  of  Burroughs  compatible  devices 
were  found  available  under  "brand  name  or  equal" 
proc ur em en t s .  Contracts  were  given  to  alternate  sources 
resulting  in  a  pr o 1 i f er a t i o n  of  Burroughs  "work-alike"  CRTs 
(e.g.,  DATAMAX,  Delta  Datas,  ADM-31s,  etc.)* 

As  time  progressed,  Burroughs  compatible  and  even  early 
Burroughs  terminal  devices  were  found  not  always  to  be  100% 
compatible  with  Navy  unique  software,  particularly  as 
Burroughs  made  changes  to  its  protocols.  Upgrades  (i.e., 
replacement  of  chips  or  new  firmware)  were  required  to 
existing  terminals,  often  free  if  Burroughs  had  provided 
them  and  not  so  when  obtained  from  third  parties. 
Additionally,  projects  began  to  request  greater 
functionality  (e.g.,  multiple  function  key  support,  large 
amounts  of  terminal  memory,  etc.)  than  the  older  Burroughs 
terminals  or  compatibles  supported.  The  need  to  accommodate 
other  terminal  devices  and  protocols  was  realized. 

These  events  influenced  NAVSUP  to  require  multi-vendor 
terminal  and  protocol  support  within  the  SPLICE  procurement. 
Due  to  the  large  inventory  of  Burroughs  and  compatible 
terminals  at  the  stock  points,  both  CRTs  and  remote 
printers,  SPLICE  would  not  only  require  full  support  for 
existing  Burroughs  devices,  but  would  also  require  support 


for  a  series  of  compatibles  and  a  range  of  non-compatible 
devices,  most  noteworthy  oeing  those  manufactured  by  I3M  and 
ISM  compatible  devices. 63  A  summary  of  Government  Furnished 
Equipment  (GFE)  terminal  devices  which  were  listed  in  tne 
SPLICE  contract  [Ref.  86]  is  provided  below: 

1.  Burroughs  and  Burroughs  compatible  CRTs  and  remotely 
adaressaole  printers; 

2.  IBM  3270  series  devices; 

3.  IBM  2780/3780  data  communications  protocols; 

4.  and  Asynchronous,  block/forms  mode  CRTs. 

Conspicuous  by  its  absence,  is  required  support  for  PCs. 

The  words  "terminal  support"  are  nebulous.  If  one  can 
physically  connect  a  device  to  the  system  is  that  support? 

Is  protocol  support  required?  What  if  only  some  terminal 
operating  modes  are  available?  Must  one  be  able  to  run  at 
least  some  or  all  system  supported  and  application  software? 
The  answers  to  these  questions  determines  the  level  of 
foreign  terminal  support  a  system  provides. 

To  ensure  there  were  no  misunderstandings  in  this 
critical  area,  three  requirements  were  specified  for 
"terminal  support"  in  the  SPLICE  procurement: 

1.  Government  furnished  data  communication  equipment 
identified  .  .  .  shall  be  interfaced.  Data 
communications  equipment  operation  shall  be  provided 
in  both  asynchronous  and  synchronous  communications 
modes  configured  on  both  point-to-point  and  multipoint 
lines  within  the  same  SPLICE  configuration.  The 

63with  IBM  or  IBM  compatible  terminals  representing 
approximately  70%  of  the  terminal  market,  this  step  appears 
justified. 


Contractor  provided  system  functions  available  to  a 
system  user  shall  be  available  from  any  data 
communications  equipment  which  has  facilities  for 
inputting  and  outputting  the  necessary  characters,  in 
any  of  the  communications  modes  and  line 
configurations.  [Ref.  87] 

2.  The  conversion  of  received  and  transmitted  data  snail 
be  provided  such  that  tne  applications  software  snail 
be  independent  of  terminal  or  data  communications  line 
characteristics. 

3.  Data  Communications  Network  Software  shall  provide  for 
full  utilization  of  all  features  of  the  terminals 
[Ref.  88]. 

These  criteria  were  to  provide  for  use  of  all  native  mode 
terminal  capabilities,  in  all  operating  modes  and 
configurations,  requiring  all  system  software  and 
applications  to  fully  function  as  if  dealing  with  a  vendor 
terminal,  and  to  do  so  without  application  software  or 
configuration  changes.  Vendors  were  required  to  demonstrate 
portions  of  this  support  at  the  SPLICE  benchmarks. 

The  winning  vendor,  FDC,  was  able  to  demonstrate  full 
compliance  with  the  SPLICE  specifications  at  the  benchmarks, 
in  terms  of  the  "letter  of  the  law."  TANDEM  off-the-shelf 
hardware  and  software  provided  physical  connectivity, 
protocol  support,  as  well  as  higner  level  TANDEM  product 
interface  for  TANDEM  terminals  and  IBM  devices.  FDC 
provided  software  to  perform  data  format  mapping  and 
interface  to  higher  level  TANDEM  products  offer  irigs  for 
"dumb"  asynchronous  block/form  mode  and  Burroughs  devices. 

FDC  was  also  concerned  enough  about  the  SPLICE  project 
and  the  many  initiatives  that  it  had  to  support  in  an 


operational  environment  to  inform  tne  government  at  that 
time  of  deficiencies  in  their  demonstrated  package  that 
would  require  extensive  revisions  to  meet  all  the  "spirit  of 
the  law"  requ irements .  The  software  package  wnich  resulted 
from  this  re-write,  which  was  performed  at  no  cost  to  the 
government,  is  today  called  TMAP. 64 

Specifically,  TMAP  supports  the  following  functions  for 
government  furnished  terminal  equipment: 

1.  supports  hardware  interface  and  communications  level 
protocol  for  GFE  terminals  in  various  point-to-point 
and  multipoint  configurations; 

2.  provides  an  operating  mode  which  allows  block  mode 
applications  written  in  PATHWAY  to  treat  GFE  terminals 
as  if  they  were  TANDEM  6530  terminals;  65 

3.  provides  an  operating  mode  which  allows  conversational 
or  teletype  access  to  the  Command  Interpreter,  FUP, 
EDIT,  etc . ; 

4.  provides  an  operating  mode  which  allows  access  to  GFE 
printers  by  the  TANOEM  SPOOLER; 

5.  supports  virtual  function  key  support  for  GFE  CRTs; 

6.  and  performs  the  above  in  a  manner  which  makes  the 
terminal  type  transparent  to  the  application  program. 


64in  that  TANDEM  and  I8M  terminals  are  supported 
completely  with  off-the-shelf  products  and  there  are  so  few 
of  these  currently  in  the  stock  point  inventory,  government 
interest  has  focused  most  closely  on  TMAP.  This  interest 
will  remain  high  as  other  terminals  from  the  remainder  of 
the  BUNCH  ( i . e . ,  Burroughs,  Univac,  NCR,  CDC,  and  Honeywell) 
must  be  interfaced  to  SPLICE. 

^Although  FDC  documentation  states  TANDEM  6  5  3  0 
emulation  is  provided,  due  to  limitations  on  the  Burroughs 
CRTs,  TANDEM  6510  terminal  emulation  appears  closer  to  what 
is  be  i  ng  prov  id  ed  . 


There  was  sufficient  functionality  provided  here  to  permit 
implementation  of  immediate  application  packages  at  the 
stock  points  using  previously  procured  Burroughs  and 
compatible  devices,  as  augmented  by  SPLICE  procured  TANDEM 
6530  terminals.  [Ref.  89] 

As  a  part  of  the  recently  accepted  FDC  SPLICENet 
proposal,  TMAP  functionality  will  be  transitioned  to  a  new 
FDC  product  for  TANDEM  called  the  Communications  Control 
Process  (CCP).  A  copy  of  CCP  will  reside  in  every  SPLICE 
system  at  a  site  under  the  control  of  a  site  Communications 
Environment  Manager  (CEM).  Within  CCP  are  vendor  unique 
terminal  handling  processes  called  Terminal  Initialization 
(TERM  IN  IT)  processes.  Four  TERM  INIT  processes  are 
currently  recognized  by  FDC  as  being  required:  IBM  3270,  IBM 
SNA,  Burroughs,  and  Honeywell.  [Ref.  90] 

Future  stock  point  processing  will  require  the 
incorporation  of  intelligent  workstations  or  PCs  onto  SPLICE 
( i . e . ,  APADE).  IBM  PC  or  compatible  PC  support  can  be 
provided  under  SPLICE  in  four  ways: 

1.  The  government  can  procure  TANDEM  DYNAMITE 
workstations,  which  are  IBM  compatible  PCs. 

2.  PCs  may  be  interfaced  to  SPLICE  systems  as  TANDEM  6530 
terminals  via  third  party  terminal  emulation  packages, 
such  as  the  Microgate  6530  board/software.  Using  the 
Microgate  6530  product,  in  addition  to  terminal 
emulation,  a  data  file  upload  and  download  software 
package,  with  format  translation,  is  available 

( FLASH)  . 

3.  TANDEM  itself  supports  a  PC  interface  package  called 
PC  LINK,  usable  with  the  6100  communications 
subsystem. 


4.  TANDEM  has  announced  support  for  a  PC  LAN  interface, 
which  will  include  the  capability  for  PCs  on  a  Local 
Area  Network  (LAN)66  to  emulate  TANDEM  6530  terminals. 
Additional  support  includes  the  ability  of  PCs  on  the 
LAN  to  use  TANDEM  disk  storage  as  a  local  PC  drive 
(FILE  SERVER),  and  share  printers  (PRINT  SERVER). 

Many  command  interpreter  commands  to  the  TANDEM 
systems  may  be  entered  in  PC  formats  with  the  TANDEM 
system  making  required  conversions  to  TANDEM  formats. 

Although  the  authors  were  unable  to  locate  SPLICE 
contract  modifications  including  any  of  these  products, 
SPLICE  system  users  are  planning  to  obtain  many  of  these 
products  (i.e.,  NSC  Pearl  Harbor).  All  these  products  could 
be  provided  under  the  SPLICE  contract  substitution  clause. 

The  benefits  that  the  corporation  receives  from  SPLICE 
supporting  terminal  i n tero per ab i  1  i ty  are  fourfold: 

1.  SPLICE  can  introduce  new  applications  to  the  stock 
points,  including  new  functionality  in  the  interim  to 
SPAR,  while  protecting  the  existing  terminal  Dase. 

This  allows  for  phased  terminal  augmentations  or 
enhancements,  selective  terminal  replacement  as 
devices  reach  obsolescence,  and  greater  time  periods 
over  which  to  extend  replacement  costs. 

2.  SPLICE  allows  terminal  replacement  contracts  to  be 
more  functional  vice  vendor  product  or  interface 
specific.  This  enables  greater  competition  in  the 
procurement  process  and  should  result  in  lower 
terminal  replacement  costs. 

3.  SPLICE  allows  a  single  terminal  to  access  multiple 
collocated  or  remote  hosts,  with  the  SPLICE  system 
handling  protocol  and  data  format  conversions  and 
permits  multiple  uses  of  a  terminal  on  the  same  host 
(i.e.,  word  and  data  processing).  This  reduces 
required  outlays  for  multiple  terminals  when  multiple 


^Advance  product  announcements  indicate  support  for  any 
LAN  product  using  the  "NETBIOS"  standard  and  which  provides 
PC  h a r d wa r e/ so f t wa r e  to  connect  to  the  network.  Planned 
support  includes:  IBM  TOKEN  Ring,  STARLAN,  PC-Network, 
Ungermann-Bass  ETHERNET/OSI  and  ETHERNE T/ TCP- I  P  . 


incompatible  host  access  or  single  nost  multifunction 
usage  is  requ  ir ed . 

4.  SPLICE'S  ability  to  use  multiple  vendor  terminals  to 
access  TANDEM  resident  applications  and  applications 
on  IBM  or  Burroughs  hosts  will  permit  a  phased 
terminal  transition  to  SPAR  without  having  to  disrupc 
the  communication  network  or  have  to  perform  a  massive 
replacement  of  older  terminal  devices  immediately. 

These  benefits  have  both  monetary  and  risk  reducing  aspects. 

There  appears  to  be  no  need  to  migrate  terminal 
i n tero per ab i 1 i ty  from  SPLICE  to  SPAR.  By  the  time  SPLICE  is 
replaced  by  SPAR  in  the  1990s,  all  stock  point  terminals 
will  have  been  replaced  with  SPAR  compatible  devices.  More 
importantly,  the  SPAR  single  vendor  support  concept  and 
reluctance  to  use  environmental  software  developed  uniquely 
for  the  Navy  would  preclude  migration  of  this  function 
simply  to  further  system  i n teroper ab i  1  i ty .  DDN  must  be  made 
to  provide  required  terminal  interoperability  for  SPAR. 

SPLICE  terminal  i n tero per ab  i  1  i  ty  supports  the  following 
proposed  SPLICE  project  objectives:  1,  12,  13,  15,  16,  19, 
23,  29,  32,  33,  34,  35,  41,  44,  49,  and  50. 

The  authors  have  five  recommendations  to  improve  SPLICE 
support  for  terminal  interoperability: 

1.  Investigate  the  inclusion  of  Univac  CRTs  and  Data 

General  CAD/CAM  terminal  devices  under  TANDEM  physical 
and  protocol  support  and  FDC  CCP/TERM  INIT  support. 

a.  The  NARDAC  U 1 1 0 0  systems  will  often  be  collocated 
with  UADPS-SP  B ur roug h s/ SPL  I  CE  systems.  Permitting 
Univac  terminals  (i.e.,  UTS  20,  UTS  30,  UTS  40, 
and  SperryLink  devices)  on  SPLICE  to  access  both 
UADPS-SP  applications  and  U1100  applications 
(i.e.,  Naval  Air  Rework  Facility  applications)  may 
reduce  the  numbers  of  terminals  required  for  users 
to  perform  their  work,  reduce  local 


telecommunication  line  costs,  and  increase  the 
range  of  potential  future  terminal  replacement 
vendors. 

b.  The  EDMICS  interface  to  SPLICE  may  be  possible  by 
supporting  the  Data  General  CAD/CAM  terminals  on 
SPLICE  hosts  via  a  pass-through  mode  to  the  EDMICS 
hosts.  This  interface  would  be  similar  to  what  is 
done  today  in  EM3270  for  TANDEM  terminals  to  work 
with  IBM  hosts. 

2.  Expand  the  scope  of  CCP  support  to  include  additional 
printers,  including  laser  printers  for  APADE,  ABE, 

LOG  MARS,  and  NISTARS.  At  a  minimum,  those  devices 
used  today  in  NISTARS  should  be  addressed. 

Additionally  investigate  the  incorporation  of  large 
volume  laser  printer  support  (i.e..  Xerox  9700)  either 
through  direct  connection  to  SPLICE  system,  through 
HYPERchannel  (type  A  or  B)  or  HYPERbus  connections,  or 
data  communications. 

3.  Review  the  functional  descriptions  of  the  TMAP 
replacement  products  in  light  of  the  SPLICE  contract 
terminal  r eq u i r em en t s .  It  is  unclear  to  the  authors 
if  full  function  support  for  dumb  block/form  mode 
asynchronous  devices  is  available  under  TMAP  today  or 
will  be  provided  under  CCP  (i.e.,  no  TERM  INIT  process 
identified).  Either  the  contract  or  the  proposal  may 
require  change. 

4.  Ensure  that  dial-in  support  for  intelligent 
terminals/PCs  is  addressed  under  CCP  and  SAS, 
including  a  file  up! oad/downl oad  facility. 67  Physical 
security  requirements  for  dial-in  support  should  also 
be  re- ex  am i ned . 

5.  FDC  should  be  tasked  with  including  local  area  PC  and 
terminal  network  support  under  SPLICENet.  PC  networks 
may  be  the  basis  of  interim  0A  at  the  stock  points  and 
NAVSUP  already  has  prototype  local  area  terminal 
networks  in  place,  which  may  not  be  compatible  with 
SPLICENet  (i.e.,  NSC  San  Diego  PLANet). 

This  concludes  the  discussion  on  terminal 
i  n tero per ab i 1 i ty .  The  topic  of  SPLICE  support  for  intra¬ 
site  i n tero per ab i 1 i ty  will  next  be  discussed. 

6  7  T  h  i  s  area  must  be  addressed  in  support  of  shipboard 
users  not  having  direct  connect  SPLICE  access. 


C.  INTRA-SITE  INTEROPERABILITY 

Intra-site  i n t ero per ab i 1 i ty  within  SPLICE  is  planned  to 
be  accomplished  in  three  ways:  TANDEM-to-TANDEM  local 
interconnection;  the  LCN  interconnection,  and  data 
communications  interconnection.  Each  of  these  methods  will 
be  addressed  to  show  how  it  accomplishes  intra-site 
i n tero per ab i 1 i ty .  Following  this,  the  benefits,  SPAR 
migration  need,  proposed  SPLICE  objectives,  and 
recommendations  for  improvements  in  this  area  will  be 
prov id  ed  . 

1 .  TANDEN- to-TANDEM  Interconnection 

With  the  definition  of  interoperability  provided  at 
the  beginning  of  this  chapter,  one  might  ask:  why  discuss 
TANDEM-to-TANDEM  interconnection?  Isn't  that  a  single 
vendor  situation?  Surprisingly,  the  answer  is  no. 

A  SPLICE  TANDEM  system  will  consist  of  from  2  to  16 
processors.  A  single  SPLICE  site  (i.e.,  NSC  Oakland)  may 
have  several  16  processor  SPLICE  systems.  Should  these  be 
interconnected?  If  so,  what  is  the  best  way  to  interconnect 
them:  via  TANDEM  products  or  via  the  LCN?  Additionally,  a 
stock  point  may  have  a  Sperry  Univac  provided  TANDEM  Non- 
Stop  II  system  for  NISTARS  which  need  not  be  configured  to 
account  for  or  operate  with  SPLICE.  The  issue  of  connecting 
multi-vendor  TANDEM  configurations  must  also  be  addressed. 

The  authors  contend  that  all  SPLICE  systems  at  a 
site  should  be  interconnected  via  TANDEM  products.  This 


provides  for  the  greatest  possible  spread  of  processes  and 
files  across  available  assets,  should  facilitate  multiple 
application  tuning  efforts,  and  provides  additional 
contingency  resources  without  r eco n f  ig ur a t  i  o n .  However, 
there  are  also  performance  factors  in  this  contention. 

The  TANDEM  host  interface  product,  EXPAND/FOX,  is 
preferred  over  the  non-TANDEM  LCN  due  to  effective  data 
transfer  rate  considerations  and  processing  software 
considerations.  An  effective  data  transfer  rate  of  1 
megabyte/ second  (per  cable  with  up  to  four  cables)  [Ref.  91] 
can  be  attained  through  TANDEM  off-the-shelf  products  while 
only  a  300  k i 1 ob y te s/ s ec o nd  burst  rate  [Ref.  92]  is 
achievable  through  the  LCN  (TANDEM  HYPER  Link)  interface 
controller.  Additionally,  the  TANDEM  EXPAND  software  has 
been  specifically  incorporated  into  and  optimized  for  the 
operating  system,  while  the  LCN  software,  NETEX  or  TABU,  is 
essentially  an  application  add-on. 

The  authors  have  already  taken  the  stand  in 
discussing  the  NISTARS-SPLICE  interface  that  the  two 
configurations  at  a  site  should  be  interconnected.  Besides 
the  appl ication  integration  advantages  from  doing  this, 
backup  and  contingency  concerns  drive  this  recommendation. 
The  question  of  how  this  should  be  accomplished,  physically 
and  with  what  software,  remains  to  be  addressed. 

The  recommended  means  to  provide  TANDEM-to-TANDEM 
system  interface  intra-site,  regardless  of  the  physical 


media,  is  through  a  bundled  software  extension  to  the  TANDEM 
operatirg  system  called  EXPAND.  This  operating  system 
extension  enables  systems  which  are  not  connected  via  the 
DYNABUS68  to  operate  as  if  they  were  a  single  system  without 
application  program  changes.  The  methods  used  to  accomplish 
this,  along  with  product  features  and  components,  are 
described  in  [Ref.  93].  For  the  purposes  of  this  document, 
it  is  only  important  to  note  that  EXPAND  permits: 

1.  a  process  on  one  node  to  access  and  use  resources, 
including  files,  on  other  nodes; 

2.  users  on  any  node  to  access  processes  or  data  on  any 
other  node,  subject  to  security  constraints; 

3.  a  process  on  one  node  to  send  or  receive  transactions 
to  and  from  a  process  on  another  node; 

4.  and  guaranteed  end-to-end  data  integrity  and 
notification  to  the  sending  process  of  delivery 

fail ur  e . 69 

All  of  these  capabilities  are  of  use  in  intra-site,  NISTARS 
TANDEM- to-SPLICE  TANDEM  interconnection. 

Physically,  the  EXPAND  software  can  use  any  of  four 
media  to  complete  system  interconnection:  direct  connect, 
fiber  optic  cables,  X.25  lines,  or  satellite  transmissions. 
Only  the  former  two  are  of  interest  in  the  area  of  SPLICE 
intra-site  connectivity  due  to  the  cost  and  distance 
involved.  The  authors  purpose  that  SPLICE  TANDEM-to- 

68jhe  DYNABUS  is  a  high  speed  i n ter - pr oc e s so r 
communications  bus  for  single  TANDEM  systems  (i.e.,  up  to  16 
processors) 

^"Guaranteed"  delivery  is  not  provided,  although  this 
too  can  be  provided  via  an  interface  to  TRANSFER. 


NISTARS  TANDEM  interconnection  be  accomplish  preferably  via 
the  TANDEM  EXPAND/FOX  fiber  optic  subsystem  (FOX),  where  tne 
distance  between  systems  is  less  than  1  kilometer  and 
sufficient  slots  can  be  found  to  support  the  FOX  controllers 
on  all  systems.  The  lesser  preferred  alternative  would  be 
interconnection  through  EXPAND/D  irect  Connect  links,  using 
the  highest  speed,  best  grade  data  lines  available  at  a  site 
(up  to  56  k i 1 oby te s/ sec o nd )  . 

2.  The  LCN  Intra-site  Interconnection 

SPLICE  systems  will  be  collocated  with  non-TANDEM 
systems.  These  non-TANDEM  systems  include  IBM,  Burroughs, 
Univac,  and  PE  systems.  The  need  to  interface  these  systems 
for  transaction  and  bulk  file  passing  appears  to  exist. 

Two  basic  concepts  of  SPLICE  have  always  been  that 
all  computers  collocated  with  SPLICE  would  be  interconnected 
to  each  other  and  SPLICE  via  the  LCN,  and  that  off-the-shelf 
software  would  be  used  to  support  the  LCN.  In  accordance 
with  the  SPLICE  contract,  this  would  mandate  use  of  Network 
Systems  Corporation  HYPERchannel s  and  Network  Executive 
(NETEX)  software.  To  date,  neither  of  these  concepts  has 
been  exploited  within  SPLICE,  although  the  SPLICENet 
proposal  re-affirms  the  latter.  Current  SPLICE  LCN 
initiatives  support  the  intra-site  interconnection  of  only 


TANDEM  and  Burroughs  systems  and  this  is  done  through  Navy 
developed  software. 70 

The  reasons  for  these  deviations  from  original 
SPLICE  plans  are  varied.  First,  consider  non-ADP  issues: 

1.  N’AVDAC  has  never  approved  a  SPLICE-111100  interface  via 
the  LCN.  This  is  the  case  in  spite  of:  the  UADPS-SP 
Burroughs  to  NIMMS  ( U 1 1 0  0 )  interface  r equ i r em en t , 7 1  a 
similar  NARDAC  New  Orleans  HYPERchannel  project 
exists,  and  general  NARDAC  NARF  support  were  the 
driving  forces  Dehind  the  original  requirement.72 

2.  FMSO  application  development  personnel  were  not 
brought  into  the  planning  process.  NAVSUP  application 
support  (e.g.,  FMSO  developed  PE  IDA)  was  the 
rationale  for  a  SPLICE-PE  interface,  particularly  in 
the  area  of  transaction  passing  to  the  Burroughs  and 
bulk  file  transfers  to  eliminate  tape  handling  at 
stock  points.  Once  the  SPLICE  contract  was  in  place 
making  development  of  these  interfaces  possible,  it 
was  FMSO  application  personnel  that  claimed  there 
existed  no  need  for  such  an  interface  since  existing 
tape  passing  was  working  and  application  changes  and 
costs  to  implement  the  changes  outweighed  benefits. 

3.  Inability  of  disparate  projects  to  acknowledge  and 
accept  areas  of  overlap.  In  many  of  the  stock  points 
the  SPLICE,  IDAFIPS,  and  NAVSCIPS  systems  will  be 
within  LCN  connection  range.  No  plans  exist  to 
connect  these.  SPLICE  sites  at  the  ICPs  will  be 


7 0 W i t h  the  exception  of  the  SPLICE  Computer  Operations 
Manual,  all  FMSO  and  FDC  SPLICENet  documentation  held  by  the 
authors  discusses  the  NETEX  software  as  being  used  to 
support  SPLICE  HYPERchannel  operations.  The  best 
information  obtainable  by  the  authors  is  that  TABU,  the  Navy 
developed  HYPERchannel  software,  is  being  used  and  will 
continue  to  be  used  in  lieu  of  NETEX  on  the  Burroughs  systems 

7 1 T  h  i  s  interface  is  accomplished  today  by  a  PE 
minicomputer  which  is  used  to  do  little  more  than  pass 
transactions  between  Burroughs  and  Univac  hosts. 

72No  response  was  received  to  letters  written  to  NAVDAC 
requesting  clarification  on  this  issue. 


connected  to  ISM  3080/3090  series  systems  via  data 
communications  (i.e.,  SNA).  7 3 

Second,  consider  the  following  ADP  related  issues: 

1.  SPLICE  LCN  software  requirements  witnin  the  contract 
called  for  interconnection  software  that  meets  ISO  OSI 
standards  for  interconnection  [Ref.  94].  This  is  so 
despite  the  fact  that  two  SPLICE  sponsored  studies  as 
NPS  Monterey  indicated  this  would  be  unnecessary 
overhead  and  it  would  adversely  affect  host/LCN 
performance.  [Refs.  95  and  96]. 74 

2.  The  preliminary  deliveries  of  Burroughs  NETEX 
confirmed  the  performance  problem  cited  in  the  studies 
since  the  software  could  only  be  run  on  larger  Navy 
Burroughs  systems  and  then  only  at  the  sacrifice  of 
some  application  processing.  Therefore,  the  Navy 
developed  their  own  HVPERchannel  software  for  the  two 
immediately  required  systems  (i.e.,  TABU).  The 
authors  anticipate  that  similar  capacity  and 
performance  problems  will  exist  on  smaller  PE  systems. 

3.  Off-the-shelf  NETEX  software  does  not  provide  all  the 
functionality  required  (i.e.,  layers  up  to  and 
including  presentation)  in  the  SPLICE  contract.  FDC 
was  required  to  supplement  it  with  additional 
software.  This  required  development  time  after 
delivery  of  acceptable  lower  level  software  products 
and  would  not  meet  Navy  implementation  schedules. 

This  area  too  is  under  re-design  in  SPLICENet.75 


7^The  rationale  for  this  is  unclear  to  the  authors. 
Explanations  from  lower  level  FMSO  personnel  include  that 
HYPERchannel  is  not  recognized  as  an  "IBM  strategic  product" 
and  the  interface  would  require  the  use  of  "Navy  unique 
software"  to  implement. 

74to  obtain  off-the-shelf  software  in  the  contract  it 
was  necessary  to  specify  some  standard.  The  ISO  OSI  standard 
was  the  only  one  seen  as  av a i 1 ab 1 e/ appl i c ab 1 e  to  the  SPLICE 
system,  including  the  LCN. 

7  5  The  SPLICENet  proposal  indicates  that  a  SNA  like 
hierarchy  would  be  established  for  HYPERchannel /NETEX  usage. 
A  CCP  would  control  LCN  usage  through  Communications 
Interface  Packages  (CIPs)  on  each  background  host  processor. 
These  CIPs  interface  to  HYPERchannel  via  NETEX.  When  a  CIP- 
to-CIP  session  is  required,  the  CCP  accomplishes  it. 


The  use  of  the  Navy  developed  HYPERchannel  software 
in  SPLICE  for  TANDEM  and  Burroughs  has  thoroughly  proven  the 
concept  of  high  speed  inter-computer  communications  for 
i  n t ero per ab  i  1  i  ty  within  the  stock  point  environment. 
Previously,  the  REP  FILES  and  TRANSRECON  Offload 
applications  were  discussed  supporting  this.  The  other 
major  proof  of  this  is  found  in  the  Navy  developed  Burroughs 
Pre-Processing  module  on  SPLICE. 

The  Burroughs  Pr e-Proc e s s  i  ng  module  permits:  1. 
users  on  SPLICE  terminals  or  processes  to  obtain  access  to  a 
pass  through  application;  2.  creation/storage/present^tion 
of  TANDEM  screen  images  of  Burroughs  frames  for  optional 
use;  and  3.  passing  of  SPLICE  generated  standard  Burroughs 
transactions  to  on-line  Burroughs  programs  or  queues.  Once 
in  the  pass  through  application,  inputs  are  passed  out  of 
SPLICE,  through  the  HYPERchannel,  and  to  the  Navy  Burrougns 
data  communications  manager  (SDCH),  while  Burroughs  outputs 
are  passed  back  via  a  similar  path  to  input  CRTs,  remote 
printers  located  on  SPLICE,  or  may  be  inputs  to  holding 
files  or  other  processes.  When  the  Burroughs  systems  are 
down,  Burroughs  destined  inputs  are  stored  for  future 
passing  to  them.  Unexpected  Burroughs  generated 
transactions  may  also  be  passed  to  SPLICE  via  this  module 
and  forward  to  SPLICE  proc e s se s/ f  i  1 e s  .  [Refs.  97  and  98] 

The  authors  found  no  documentation  concerning  a  Navy 
unique  im  pi  em  en  t  a  t  i  o  n  of  a  bulk  file  transfer  module  using 


the  HYPERchannel  s  and  TABU.  Although  such  development  is 
well  within  FMSO's  capability,  it  appears  that  future  N  E  T  E  X 
releases  may  be  used  to  fill  this  role,  eliminating  the  need 
for  furtner  Navy  unique  development. 

3 .  Data  Communications  Interconnection 

In  light  of  the  failure  of  the  LCN  concept  being 
exploit ed,  some  stock  point  intra-site  computer  connectivity 
will  still  require  data  communications  interfaces.  In  these 
situations,  SPLICE  can  perform  the  required  interface 
function  for  terminal  users  and  processes. 

In  chapters  IV  through  VII,  some  of  the  NAVSUP 
applications  requiring  intra-site  data  communications 
interface  are  discussed.  Specifically,  these  are  FMSO  IDA, 
NAVADS,  NISTARS,  and  On-Line  AUTODIN  (OLA). 

FMSO  IDA,  NAVADS,  and  OLA  are  planned  to  transition 
to  SPLICE,  therefore,  no  effort  appears  necessary  to 
interface  their  current  data  communications  requirements  to 
SPLICE. 76  These  transitions  to  SPLICE  also  obviate  the  need 
for  the  PE  LCN  interface  entirely  within  NAVSUP.  NAVSCIPS 
and  NIMMS  still  present  unresolved  PE  interface  problems. 

Recommendations  were  previously  made  to  eliminate 
the  N I STA RS- to- B ur ro ug h s  data  communications  interface  and 
replace  it  with  direct  TAND EM- t o- T AND  EM  connections.  The 
FDC  SPLICENet  proposal  specifically  addresses  the  EXPAND/FOX 

76If  it  were  necessary  to  do  this,  the  current  NAVADS- 
to-NISTARS  data  communications  interface  could  easily  be 
incorporated  into  SPLICE. 


interface  required  in  this  case  and  alludes  to  the 
alternative  E XP AND / D  i  r ec t  Connect  interface  as  an  exception 
for  MAPS  RJE  site  processing.  To  accomplish  the  NISTARS- 
SPLICE  interface,  this  exception  may  be  the  rule  aue  to 
distance  between  systems. 

Outside  of  3ur r o ug h s- to- B u r ro ug h s  terminal 
concentrator  and  RJE  intra-site  data  communications,  whicn 
can  be  eliminated  by  moving  terminals  and  processing 
directly  over  to  SPLICE,  there  is  only  one  other  firm  intra 
site  data  communications  interface  required:  IBM-to- 
SPL I C E / B ur ro ug h s .  This  interface  is  required  in  support  of 
the  TRIDENT  LDS,  but  will  also  apply  to  the  ICP 
Re  so  1  i  c i ta t i o n  system  interface.  These  systems  prefer 
standard  System  Network  Architecture  (SNA)  SPLICE  interface 
over  HYPERchannel  interface. 

The  TRIDENT  LDS  system  has  recently  been 
transitioned  from  PE  equipment  to  IBM  4300  series 
hardware/software  obtained  off  the  ICP  Resolicitation 
contract.  Part  of  this  transition  required  the  replacement 
of  the  previous  TRIDENT  LDS-to-UADPS  terminal  and  process 
data  communications  hard  ware  and  software  interfaces,  which 
were  called  collectively  the  NCP.  NCP  resided  on  PE 
hardware  and  connected  local  PE  systems  to  remote  Burroughs 
systems  for  transaction  passing,  while  simultaneously 
permitting  terminals  on  it  to  access  either  system.  When 
the  Burroughs  host  which  supported  a  portion  of  TRIDENT  LDS 


was  moved  to  the  TRIDENT  Refit  Facility  ( T R F )  ,  Bangor,  the 
need  to  interface  a  Burroughs  host  collocated  with  an  IBM 
host  through  data  communications  was  recognized. 

FDC  was  aDle  to  accomplish  this  through  a 
combination  of  TANDEM,  IBM,  and  third  party  software.  Three 
situations  had  to  be  accommodated: 

1.  a  user  requiring  access  to  data/processes  on  either 
the  IBM  or  Burroughs  system  on  a  regular  basis; 

2.  a  user  on  the  IBM  system  requiring  infrequent  access 
to  the  Burroughs  system; 

3.  and  an  application  on  IBM  sending  transactions  to  an 
application  on  Burroughs,  and  vice  versa. 

Situation  number  one  was  accommodated  by  placing  the 
bi-directional  terminals  on  SPLICE.  Terminal  access  to 
Burroughs  was  provided  via  the  SPLICE  Burroughs  Pre¬ 
processor  and  related  hardware/ software.  IBM  access 77  was 
provided  by  installing  on  the  TANDEMs:  EM3270  to  make  TANDEM 
terminals  able  to  emulate  IBM  32  70  terminals;78  direct 
support  of  IBM  terminals  on  SPLICE;  SNAX  which  provides  the 
SDLC  link  level  protocol  required  to  interface  to  the  IBM 


^Assumes  an  IBM  host  running  MVS  or  MVS/XA,  ACF/VTAM, 
and  CICS  or  other  LU  6.2  software. 

73jhe  authors  are  making  the  assumption  that  Burroughs 
terminals  emulating  TANDEM  6530s  via  the  FDC  TERM 
I N I T/ Bu r ro ug h s  software  (old  TMAP)  can  be  interfaced  to 
EM3270  to  enable  IBM  system  usage.  If  this  is  not  so,  much 
of  the  existing  Burroughs  terminal  base  is  in  jeopardy  and 
one  of  the  basic  tenants  of  the  SPLICE  contract  (i.e.,  full 
support  for  Burroughs  terminals)  has  been  discarded.  This 
capability  is  considered  critical. 


host  [Ref.  99],  79  and  3.  SNAX  Hign  Level  Support  (SNAX/HLS), 
which  provides  Transmission  Control  services  required  by 
SNA.  To  begin  use  of  the  IBM  system  from  a  SPLICE  terminal, 
the  user  must  self-initiate  the  session  with  an  initiation 
and  logon  request,  indicating  the  line  leading  to  the  IBM 
host  and  the  name  of  the  IBM  host  application  that  is  to 
process  the  logon  request.  SNAX  then  initiates  the  session. 
From  there,  normal  IBM  processing  continues. 

The  second  situation  is  more  complicated.  In 
addition  to  the  products  already  assumed  on  the  IBM  and 
TANDEM,  several  ofher  products  are  required.  A  product 
called  Host  Command  Facility  (HCF)  is  required  on  the  IBM 
system.  User  logon  to  this  product  permits  terminals  on  the 
IBM  system  to  interface,  through  V T AM/ S N AX / S N A X  HLS,  to  a 
FOC  provided  TANDEM  process  called  DHCFNET.  To  do  this,  the 
IBM  user  must  execute  the  HCF  software  and  then  input  an 
ACQUIRE  command,  followed  by  the  SNA  logical  unit  (LU  NAME) 
assigned  to  the  terminal.  DHCFNET  performs  mapping 
functions  and  interfaces  to  the  FDC  SAS  system.  After  a 
short  period  of  time  following  presentation  of  a  FDC  welcome 
message,  the  user  is  "pushed"  the  SAS  logon  screen,  from 

79The  TANDEM  SNAX  product  includes  a  PASSTHROUGH 
function.  This  function  permits  an  IBM  host  application 
program  to  communicate  with  TANDEM  connected  SNA  compatible 
devices  as  though  they  were  connected  to  a  host  cluster 
controller.  The  function  is  enabled  by  configuration  and 
startup  procedures,  vice  software  enabled. 


which  Burroughs  P r e- P r oc e s so r  may  be  selected  for  further 
processing  on  the  Burroughs  host.  [Refs.  100  and  101] 

The  third  situation  is  accomplished  by  adding  yet  an 
additional  product  to  the  TANDEM  for  interface  to  provide  L J 
6.2  interface  to  the  IBM  side:  SIXTWO  [Ref.  102].  Altnougn 
no  specific  references  were  found  describing  the  actual 
processing  scenario  being  used  at  TRF,  the  authors  can 
provide  a  summary  of  how  processing  can  be  accomplished. 

The  SIXTWO  product  on  TANDEM  allows  SPLICE 
applications  to  pass  transactions  to  and  receive 
transactions  from  LU  6.2  programs  on  the  IBM,  by  providing 
the  required  port  to  the  SNA  network.  Normal  SNA  services, 
such  as  Transmission  Control,  Data  Flow  Control,  Logical 
Unit  Network  Services,  Resource  Management  Services, 
Presentation  Services,  and  Control  Point  services  are 
provided  by  SIXTWO  which  interfaces  to  SNAX  using  SNALU  . 
Transaction  programs  on  both  IBM  (i.e.,  CICS/TAPS 
applications  from  TRIDENT  LDS)  or  TANDEM  (i.e.,  PATHWAY 
applications  accepting  requests  for/from  Burroughs  Pre- 
Processor)  can  both  make  calls  on  SIXTWO.  SIXTWO  initiates 
all  required  session  services  on  behalf  of  the  two  parties 
wishing  to  pass  data,  and  when  both  processes  are  on-line, 
permits  a  pass  through  of  the  initiator's  data  to  the 
reception  point.  After  acknowledgement  of  receipt,  the 
session  may  be  terminated. 


The  basic  principals  of  this  SNA  interface  between 


SPLICE  and  IBM  have  been  incorporated  into  the  new  FDC 
SPLICENet  proposal.  This  interface  is  described  as  a 
"gateway  interface",  and  pre-supposes  NETEX  instead  of  TA3U 
for  the  Burroughs  connection.  A  similar  interface  may  be 
implemented  at  both  Navy  ICPs  under  Resolicitation  for  stock 
point  access  to  ICP  programs  and  files  (i.e.,  ICPNet). 

Having  discussed  the  three  ways  in  which  intra-site 
i n tero per ab  i  1  i  ty  will  be  provided  for  under  SPLICE,  what 
benefits  which  can  accrue  from  their  implementation?  In 
terms  of  TANDEM-to-TANDEfi  intra-site  interface,  application 
integration,  resource  sharing,  and  backup/red undancy  are  all 
potential  benefits.  The  benefits  the  LCN  interface  provides 
include:  a  method  to  interface  new  applications  to  the 
Burroughs  or  a  means  to  permit  additional  terminal  access  to 
the  Burroughs  without  adding  Burroughs  workload;  a  means  to 
share  resources  among  collocated  systems;  an  alternate  means 
to  access  Burroughs  master  file  data  (i.e.,  REP  FILES);  a 
means  to  extend  the  life  of  the  Burroughs  while  awaiting 
SPAR;  and  a  vendor  independent  data  communications  subsystem 
for  SPAR.  Finally,  the  benefits  that  intra-site  data 
communications  provide  are:  SNA  compatibility  and  access; 
ability  to  share  terminals  among  different  systems;  and  the 
ability  to  pass  and  share  data  among  collocated  multiple 
vendor  systems.  This  last  benefit  is  particularly  important 
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in  that  access  to  ICP  data  for  inquiry  can  be  accomplished 
through  this  over  SPLICENet. 

Intra-site  interoperability  will  be  important  to  the 
stock  points  during  and  after  full  SPAR  implementation, 
regardless  of  their  long  term  single  vendor  concept.  There 
will  be  BBN ,  PE,  Univac,  large  scale  Burroughs,  and  possibly 
even  Honeywell  systems  collocated  with  the  new  SPAR  hardware 
at  some  stock  points.  With  SPLICE  present,  there  should  be 
no  need  to  migrate  intra-site  i n tero per ab i 1 i ty :  SPLICE  will 
provide  for  it.  However  in  long  term,  SPAR  itself  will  need 
to  accommodate  this  in  the  SPLICE  replacement  upgrade. 

Intra-site  i n tero per ab i 1 i ty  supports  or  is  supported 
by  the  following  proposed  SPLICE  objectives:  6,  8,  12,  19, 
21,  23,  26,  29,  32,  33,  41,  44,  47,  and  48. 

The  authors  recommend  the  following  actions  be  taken 
to  improve  support  in  this  area: 

1.  Perform  a  site  survey  of  planned  NISTARS  sites  to 
determine  if: 

a.  NISTARS  systems  are  close  enough  to  SPLICE  systems 
to  use  FOX; 

b.  FOX  cables  can  be  physically  run  from  the  SPLICE 
systems  to  the  NISTARS  systems; 

c.  sufficient  ports  exist  on  the  NISTARS  systems  to 
support  FOX  controllers. 

Incorporate  the  results  into  SPLICENet  plans 
indicating  required  support  by  site. 

If  TANDEM- to -TANOEM  intra-site  connections  must  use 
E XP AND / D i r ec t  Connect,  revise  the  SPLICENet  proposal 
to  elaborate  on  the  Navy  interface  requirements  to  use 
CEM. 


2. 


3.  Confirm  the  requirements  for  LCN  connectivity. 


a.  If  NAVDAC  does  not  permit  Univac  access,  delete 
the  Univac  LCN  requirement  from  the  contract  and 
the  SPLICENet  proposal. 

b.  If  FMSO  and  NAVCOMPTSSA  do  not  require  PE  access 
to  the  LCN,  delete  the  PE  LCN  requirement  from  the 
contract  and  the  SPLICENet  proposal.  80 

c.  If  ICP  and  TRIDENT  remain  disposed  to  not  using 
HYPERchannel,  reevaluate  the  purpose  of  the  ISM 
LCN  interface.  If  it  is  there  to  support  other 
older  stock  point  IBM  systems,  validate  the  system 
and  commun ications  software  now  being  used:  a  MVS 
based  plan  may  be  i na p pro pr i a te .  Revise  or  delete 
the  requirement  in  the  contract  and  the  SPLICENet 
pro  po  sal  accordingly. 

d.  Honeywell  DPS6  systems  will  be  installed  at  some 
NARDAC  sites.  Determine  if  a  LCN  interface  is 
appropriate  and  desired  for  use  there. 

e.  The  IDAFIPS  Burroughs  6900  systems  may  be 
collocated  with  other  stock  point  systems  (i.e., 
NARDAC  Jacksonville).  Determine  if  a  LCN 
interface  is  appropriate  and  desired  for  use 
there . 

4.  Reevaluate  the  SPLICE  contract  requirement  for  use  of 
the  ISO  OSI  standard  in  LCN  software.  Permit  FDC  the 
option  to  substitute  other  LCN  software  with  fewer 
layers  and  designed  to  optimize  LAN  performance  over 
redundant  and  unnecessary  wide  area  network  error 
detection  and  correction  integrity  features. 

5.  Have  FMSO  develop,  document,  and  deploy  TABU  based 
bulk  file  transfer  software. 81 

6.  Based  on  operational  data  received  to  date, 
investigate  the  optimum  configuration  for  HYPERchannel 
traffic  over  adapters,  particularly  on  the  TANDEM 
side,  as  well  as  trunk  line  dedication.  In  a  similar 


80jhere  is  probably  insufficient  capacity  on  their 
NAVSCIPS  PE  3210  systems  to  support  both  NETEX  and  PE  CIP 
anyway.  This  also  should  be  validated. 

SlThe  authors  understand  from  discussions  with  NAVSUP 
personnel  that  this  software  may  already  exist,  although 
documentation  was  not  located  on  it. 


light,  optimize  Burroughs  P r e- P r oc e s so r / TAB U  software 
to  improve  user  terminal  response  times. 


7.  Investigate  user  dissatisfaction  over  current  SNA 
terminal  connectivity  r eq u  i  r em en t s .  It  should  be 

possible  for  interface  software  to  provide  required  LU 
data  and  menu  selection  of  desired  application. 82 

This  concludes  the  discussion  on  intra-site 

i n tero per ab i 1  i  ty .  Inter-site  interoperab  il  i  ty  will  be 

add  r e  s  sed  next. 

D.  INTER-SITE  INTEROPERABILITY 

Although  someday,  inter-site  i  n  tero  per  ab  i  1  i  ty  may  be  the 
exclusive  domain  of  the  DON,  that  day  does  not  appear  to  be 
in  the  immediate  future.  Five  areas  of  inter-site 
i n t ero per ab i 1 i ty  must  be  addressed  by  SPLICE:  shore  based 
system  access,  MAPS  RJE  activity  access,  DLANet  access,  DDN 
access,  and  DAAS/ AUTODIN  I  access.  Following  a  discussion 
of  how  SPLICE  will  provide  interoperability  in  each  of  these 
cases,  benefits  to  the  corporation,  SPAR  migration  need, 
proposed  SPLICE  objectives  supporting  and  supported  by  each, 
and  recommendations  for  improvements  will  be  made. 

1 .  Shore  Based  System  Access 

Certain  shore  based  activities  such  as  Ships 
Intermediate  Maintenance  Activities  (SIMAs),  non-TRIDENT 
Submarine  8ase  Repair  Facilities,  non-deployed  air 
squadrons,  and  Naval  Shipyards,  etc.,  currently  do  and  will 
continue  to  require  interface  to  the  Navy  Supply  System. 

S 2 j h i s  r ec ommend a t i o n  is  based  on  discussions  with  FMSO 
TRIDENT  project  office  personnel. 


Many  of  these  activities  will  be  using  SNAP  I  compatible 
Honeywell  equipment:  EDM  ICS,  using  Data  General  equipment, 
is  a  notable  exception.  Some  of  these  activities  are  witnin 
a  few  miles  of  supporting  Supply  Centers  making  DDN 
interface  i  n a ppr o pr  i  a te  .  This  leaves  local  data 
communications  as  the  primary  access  media  for 
interoperability  and  horizontal/vertical  integration. 

Neither  the  SPLICE  contract  nor  the  SPLICENet 
proposal  make  reference  to  these  interfaces.  Although  there 
is  insufficient  time  in  this  study  to  investigate  and 
propose  individual  interfaces  for  these  systems,  the 
requirement  to  do  so  does  appear  to  exit,  and  SPLICE  must  be 
the  vehicle  to  meet  the  r equ i r em en t . 83 
2 .  HAPS  RJE  Activity  Access 

MAPS  is  a  Navy  unique  environmental  package,  usable 
by  both  host  and  satellite  personnel,  which  enables  better 
management  of  batch  processing  on  Burroughs  hosts.  MAPS 
provides  for:  [Ref.  103] 

1.  automatic  execution  of  a  series  or  stream  of  programs 
which  have  been  pr e-ca tal og ed .  Both  high  priority  and 
pr  e- sc  hed  ul  ed  normal  priority  jobs  may  be  executed. 

Z.  automatic  file  selection  and  verification  for  up  to 
nine  collocated  activity  codes  (i.e.,  different  users 
and  files)  operating  on  the  same  Burroughs  host. 

3.  remote  input  of  job  stream  data  files  (inputs)  from 
satellite  sites  through  data  communications.  Remote 
inputs  are  specially  validated  and  formatted  to 
prevent  erroneously  formatted  job  inputs  from  ever 


83see  Chapter  8  for  several  possible  methods  to 
interface  Honeywell  DPS  6  series  hardware. 


reaching  the  Burroughs  host  and  to  facilitate  transfer 
of  job  inputs  over  data  communications  lines  (i.e., 
com  paction  of  data). 


4.  host  output  management  including  file  collection  to 
prevent  loss,  tape  library  functions,  and  managing  of 
paper  (i.e.,  part  forms  required)  and  card  outputs. 

5.  remote  output  management  including  the  compaction  of 
outputs  satellite  bound  to  facilitate  data 

tr  an  sm  i  s  s  i  o  n  ,  the  decompaction  of  outputs  once  at  the 
satellite  for  local  pr  i  n  t  i  ng  /  p  unc  h  i  ng  ,  bulk  file 
transfers  to  satellite  disk  or  tape,  and  special 
formats  and  support  for  immediate  print  and  punch 
requirements. 

6.  inquires  to  the  host  system  for  job  or  output  status. 

7.  r e s t ar t/ r ec o v er y  support. 

8.  terminal  concentration  support  to  reduce  satellite 
telecommunication  line  costs. 

Phase  II  of  SPLICE  will  address  those  portions  of  MAPS  and 
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associated  Burroughs  software  which  support  satellite 
operations  in  terms  of  both  MAPS  RJE  satellite  activity 
system  replacement  and  data  communications  access. 84 

In  the  original  SPLICE  plans,  all  existing  MAPS  RJE 
sites  were  designated  to  receive  SPLICE  hardware.  This 
remote  SPLICE  hardware  would  be  interfaced  through  local 
data  communications  lines  and  off-the-shelf  SPLICE  software 
to  host  SPLICE  complexes  and  then  to  the  Burroughs  itself 
through  the  LCN.  Much  of  the  unique  satellite  software  used 
today  would  be  unnecessary,  as  normal  SPLICE  complex 
software  (e.g.,  Burroughs  Pass-Thru,  bulk  file  transfer, 


84a  satellite  activity  can  be  as  close  as  one  mile  away 
from  its  host  site  (i.e,  SUBASE  Pearl  Harbor)  or  several 
nundred  miles  (i.e.,  NTC  Great  Lakes).  This  potentially 
means  that  DON  may  be  used  for  MAPS  RJE  satellite  support. 


etc.)  could  be  used  to  forward  uncompacted  inputs  to  and 
receive  uncompacted  outputs  from  the  Burroughs  via  the 
SPLICE  complex.  Navy  development  could  thus  concentrate  on 
merely  supplementing  the  already  existing  SPLICE  complex 
software  with  special  satellite  software  to  validate  inputs 
to  catalogued  job  streams  and  remote  site  output  management. 

Two  problems  have  emerged  which  appear  to  be 

modifying  this  plan.  The  replacement  SPLICE  hardware  for 

all  MAPS  RJE  sites  was  not  necessarily  budgeted  for  by 

NAVSUP.  Additionally,  some  of  the  Burroughs  satellite 

hardware  currently  in  use  is  of  rather  recent  vintage  and, 

therefore,  does  not  require  immediate  replacement.  Both  of 

these  facts  seem  to  have  prompted  the  following  sentence 

which  is  taken  from  the  SPLICE  SDP  III  Executive  Summary: 

Remote  Job  Entry  (RJE)  sites  which  use  the  Burroughs 
Poll/Select  protocol  will  remain  on  dedicated  circuits  to 
the  host  Stock  Points  or  to  the  nearest  SPLICE  site.  [Ref. 
104] 

From  this  statement,  SPLICE  Phase  II  appears  now  required  to 
address  two  situations:  the  interface  of  existing  Burroughs 
MAPS  RJE  hardware  and  software  to  SPLICE  complexes  and  the 
outright  replacement  by  SPLICE  of  existing  MAPS  RJE  hardware 
and  software.  The  former  is  not  addressed  in  the  SPLICENet 
proposal,  but  the  latter  is. 

Current  MAPS  RJE  equipment  consists  primarily  of 
Burroughs  minicomputers  and  peripherals.  Over  the  years, 
this  hardware  has  slowly  been  upgraded  and  standardized 
around  the  B1900  system,  although  older  and  smaller  systems 


still  exist.  These  systems  can  support  Burroughs  terminal 
concentration,  high  priority  document  printing,  batch 
printing,  card  input/output  operations,  local  disk  and  tape 
archival  storage,  and  data  communications  interface  to  one 
or  more  Burroughs  FEPs  using  the  Burroughs  Poll/Select 
protocol . 

Interfacing  such  Burroughs  B1900  systems  to  a  SPLICE 
complex  may  prove  to  be  a  challenge.  SPLICE  should  have  no 
problem  in  accommodating  the  existing  Burroughs  Poll/Select 
protocol,  although  some  modifications  in  FDC  products  may 
have  to  be  made  to  handle  larger  record  and  block  sizes,  any 
different  c har ac t er i s t  i  c s  of  the  B  1  900  system  itself  as  both 
a  terminal  and  a  concentrator  controlling  up  to  39  other 
Burroughs  terminals,  and  any  unique  data  verification 
techniques  currently  used  to  provide  end-to-end  integrity 
between  host  and  satellite.  SPLICENet  plans  will  also 
require  changes  to  accommodate  this  foreign  host  at  a  SPLICE 
site  (cell)  level.  The  real  challenge  will  be  identifying 
and  making  B1900  Satellite  Activity  Monitor  II  and  SAM  II 
Data  Communications  Handler  software  changes  which  may  be 
required  to  accommodate  the  fact  that  they  are  not 
interfacing  to  a  Burroughs  FEP  and  SDCH  directly.  This 
interface  may  also  require  SDCH  or  other  Burroughs  host 
software  modifications  (i.e.,  MAPS). 

The  original  SPLICE  Phase  II  plans  for  outright 
replacement  of  current  MAPS  RJE  support,  less  the  B1900 


interface,  still  appear  executable.  The  authors  were  unable 
to  obtain  any  firm  documentation  on  FMSO  SPLICE  Phase  II 
design  and  development.  Questions  on  this  phase  still  to  be 
answered  include: 

1.  in  what  form  will  the  satellite  destined  output 
formats  (i.e.,  compacted  or  uncompacted  and  ASCII  or 
EBCDIC)  going  to  the  SPLICE  Complex  and  to  the  SPLICE 
satellite  be?; 

2.  how  will  the  satellite  operator  interface  to  SDCH  if 
complete  remote  Burroughs  console  capabilities  are  not 
included  in  Burroughs  Pr e-P roc e s so r ? ; 

3.  how  will  host  output  product  formats  be  interfaced  to 
the  TANDEM  SPOOLER  product  on  the  satellite?; 

4.  and  what  changes  are  required  to  Burroughs  host 
programs  to  accommodate  this  new  capability? 

Without  additional  data,  the  authors  can  say  little  more 

about  this  effort. 

3.  DLANet  Access 

A  highly  visible  and  critical  com  panion  logistics 
service  to  NAVSUP  is  the  Defense  Logistics  Agency  ( D L A )  .  In 
that  both  parties  have  recognized  this,  high  level 
agreements  have  been  made  to  permit  organizational 
components  from  both  activities  to  access  the  others'  data. 
For  purposes  of  this  document,  that  means  a  stock  point  user 
at  a  terminal  must  be  able  to  access  three  DLA  systems:  the 
Standard  Automated  Material  Management  Information  System 
(SAMMIS),  the  Defense  Integrated  Data  System  (DIDS)  and  the 
I n t e r r og a t i o n  Requirements  Information  System  (IRIS),  while 
a  DLA  terminal  user  must  have  access  to  stock  points'  MSIR, 
RDF,  RSF,  and  Excess  Status  File  (ESF)  data. 


Although  a  good  policy  decision,  these  interfaces  in 
the  absence  of  D D N 8 5  are  somewhat  complicated  due  to 
hardware,  software,  protocol,  and  geographic  distance 
issues.  For  example,  DLA  activities  use  IBM  hardware  with 
NCR  COMTEN  FEPs  using  the  Comm  unications  Networking  Software 
(CNS)  to  interconnect  their  IBM  hosts  (DLA Net)  as  a  means  to 
provide  their  users  "corporate"  access  to  data  and  systems. 
The  DLA  standard  protocol  is  BISYNC  and  the  standard 
terminal  a  3270  series  or  compatible.  On  the  other  hand, 
stock  points  with  SPLICE  use  TANDEM  and  Burroughs  hardware 
with  a  TANDEM  EXPAND/DDN  X.25  network  planned  to 
interconnect  them.  The  stock  point  standard  protocol  is 
Poll/Select  with  Burroughs  TD/MT  series  terminals  comprising 
the  bulk  of  the  inventory.  Both  systems  have  or  will  have 
network  nodes  CONUS  wide,  but  with  few  within  the  immediate 
vicinity  of  each  other. 

After  numerous  meetings,  the  technical  details  to 
provide  this  two  way  interface  were  ironed  out.  The  FDC 
SPLICENet  proposal  outlines  the  methods  and  products 
required  to  accomplish  this  [Ref.  105].  The  SPLICE  sites  at 
NSCs  Norfolk  and  Oakland  will  serve  as  stock  point  gateways 
into  DLANet.  At  these  sites,  the  SPLICE  complexes  will 
install  additional  software  and  lines  to  interface  to  DGSC 

85oLA  currently  is  not  a  DON  user,  nor  will  it  be  in  the 
immediate  future.  NAVSUP  though  SPLICE  is  a  closed 
community  DON  user,  with  plans  to  go  interoperable. 


Richmond,  V A.,  and  Defense  Depot  Tracy,  Ca.,  respectively, 
for  two  way  system  access. 

Access  to  DLANet  will  be  performed  as  follows. 
TANDEM's  EM3270  product  will  be  required  so  that  TANDEM 
terminals  can  emulate  IBM  3270  devices.  The  TANDEM  product 
TR3271  will  be  installed  to  permit  a  TANDEM  system  to  appear 
to  an  IBM  system  as  a  cluster  controller.  A  dedicated  data 
communications  line  supporting  BSC  3270  will  connect  tne 
TANDEM  system  to  the  appropriate  NCR  COMTEN  for  this  path. 

A  SPLICE  user  will  acc°ss  DLANet  only  from  the  SAS  services 
screen  at  either  of  the  gateway  SPLICE  sites.  When 
validated  as  authorized,  SAS  will  interact  with  the  local 
CCP  to  dynamically  configure  an  EM3270  process  (via  EMCOM), 
initiate  a  session  with  the  COMTEN,  and  present  the  user  the 
DLANet  signon  screen.  The  user  may  then  access  the  various 
DLANet  sy s t em s/ f i 1 e s  as  permitted  by  security  authorization. 

The  gateways  from  DLANet  to  the  SPLICE  sites  is 
slightly  more  complex  and  requires  a  second  BSC  3270  line. 

In  addition  to  the  TANDEM  software  already  mentioned,  two 
additional  products  are  required:  AM3270,  to  provide  support 
for  the  in-coming  3270  line  from  the  NCR  COMTEN,  and  TERM 
INIT/3270,  to  perform  session  services  and  mapping  between 
3270  data  streams  and  the  TANDEM  6530  PATHWAY  format.  There 
is  also  a  new  software  package  required  for  the  NCR  COMTEN: 
the  Multiple  Access  Facility  with  the  Remote  Host  Option 
(MAF/RH0).  This  software  identifies  the  TANDEM  systems  as 


remote  hosts  which  are  allowed  to  be  accessed  by  tne 
remainder  of  tne  DLANet  system. 

For  a  DL A  user  to  access  a  SPLICE  gateway,  he  must 
request  access  to  SPLICENet  from  the  MAF/RHO  option 
selection  at  his  site.  Previously  executed  TERM  IN  IT/3270 
processes  will  have  opened  the  AM3270  processes  and  have 
been  placed  in  a  wait  state.  When  an  AM3270  process 
receives  a  positive  response  to  its  poll  of  its  MAF/RHO 
subdevices,  TERM  INIT/3270  assumes  control  of  the  session 
and  pushes  the  SAS  logon  screen  to  the  DLA  user.  Once 
signed  on,  the  DLA  user  may  transverse  SPLICENet  in 
accordance  with  his  security  access  authorizations. 

The  above  described  DLANet  access  is  currently  in 
the  process  of  being  implemented. 

4.  DDN  Access 

Among  its  roles,  the  DDN  is  the  mandatory 
telecommunications  interface  for  ADP  systems  and  data 
networks  [Ref.  106].  As  such,  SPLICE  must  interface  to  it 
and  utilize  it  in  support  of  many  NAVSUP  long-haul 
communications  and  interoperability  initiatives.  In 
addition  to  stock  points,  SPLICE  was  also  tasked  to  fulfill 
these  requirements  on  behalf  of  the  ICPs  and  TRIDENT  LDS. 

The  SPLICE  plan  to  interface  to  DON  consists  of  at 
least  two  phases.  A  phased  approach  is  required,  since  it 
was  not  possible  to  obtain  any  of  the  full  suite  of  DOD 
mandated  DDN  protocols  off-the-shelf  in  the  SPLICE 


pr  oc  ur  ein  en  t .  Also,  tne  phased  approacned  is  required  since 
various  DDN  project  waivers  permit  users  different  amounts 
of  time  before  they  must  become  i n tero per ab 1 e  ,  while  SPLICE 
must  be  interoperable  to  many  activities  immediately.  Tne 
two  known  phases  are  described  below.  [Ref  107] 

In  the  first  pnase,  SPLICE  will  interface  to  the  DDN 
network  as  a  closed  community.  Under  this  phase,  SPLICE 
sites  will  use  TANDEM  EXPAND  with  a  CCITT  or  basic  X.25  line 
and  host  interface  to  DON  Interface  Message  Processors 
(IMPs).  The  IMPS  will  use  essentially  dedicated  basic  X.25 
transmission  lines  to  reach  other  SPLICE  nodes.  Without  TCP 
and  IP  and  while  using  basic  X.25  under  EXPAND  within  tne 
DON  backbone,  SPLICE  will  remain  a  closed  community. 

During  this  phase  SPLICE  will  probably  only 
implement  a  stock  point  mail  system,  permit  selected  users 
to  logon  to  other  sites  via  Command  Interpreters ,  and  permit 
the  non-DDA  sites  to  pass  DDA  transmission  packages  to  the 
DDA  gateway  s  i  t  e ( s )  .  8  6  No  plans  have  been  located 
indicating  that  any  "network"  applications  will  be  developed 
during  this  phase.  Gateways  to  and  from  OLA,  I C P ,  and  DAAS 
(i.e,  via  a  DDA  gateway)  will  be  used  employing  local  or 
non-DDN  transmission  lines.  Users  and  processes  will  be 
required  to  logon  to  the  gateway  sites  over  the  closed 

86in  the  interim  to  DAAS  using  DDN  on  an  i n tero per ab  1  e 
basis,  SPLICE  will  access  DAAS/AUTODIN  I  via  a  gateway  anu 
DDA.  See  the  next  section  for  a  discussion  of  DDA. 


community  EXPAND/X.25  network,  and  then  use  the  various 
gateway  applications  and  processes  from  there. 

In  the  second  phase,  long  haul  i  n ter o per ab 1 e 
SPLICEnet  will  begin  to  be  implemented.  The  original  direct 
EXPAND/basic  X.25  interface  to  the  DON  IMP  will  be 
supplemented  with  a  FDC  provided  DDN  interface  controller, 
which  will  still  interface  to  the  SPLICE  TANDEM  system  via 
CCITT  X.25,  but  to  the  DDN  IMP  with  either  CCITT  X.25  or  DDN 
Standard  X.25.  The  controller  itself,  made  by  Communication 
Machinery  Corporation,  will  map  CCITT  basic  to  DDN  Standard 
X.25,  as  well  as  have  TELNET,  TCP  and  IP  resident  on  it. 
Revised  FDC  SAS  and  CEM  software  packages  will  also  be 
required  in  this  phase  [Ref.  108]. 

Phase  II  will  permit  either  closed  community  or 
interoperable  DDN  interface  on  a  line.  In  that  two  DDN 
lines  are  planned  at  each  large  SPLICE  site,  both  closed 
community  and  i n tero per ab 1 e  lines  can  be  maintained 
concurrent! y :  the  CCITT  X.25  line  under  EXPAND  for  SPLICE  to 
SPLICE  connectivity  and  the  DOD  Standard  X.25  line  under 
normal  DOD  protocols. 87  ftp  and  SMTP  will  be  implemented  on 
the  TANDEM  processors.  Again,  no  reference  is  made  to  any 
applications  which  will  use  or  support  the  DDN  protocols. 

87Although  not  addressed  in  the  SPLICENet  proposal,  it 
would  be  advantageous  to  have  EXPAND  work  with  DDN  Standard 
X.25  as  an  option  rather  than  CCITT  X.25.  If  this  is  done, 
the  CCITT  (basic)  X.25  lines  currently  in  use  by  NAVSUP  can 
be  released  with  no  loss  in  SPLICE-to-SPLICE  site 
f unc  t ional i ty . 


It  is  not  clear  from  the  SPLICE  project  documentation  or  the 
SPLICE  Net  proposal  if  non-SPLICE  DON  users  who  do  access  a 
SPLICE  site  with  TELNET  will  have  any  SPLICE  resident 
applications  available  to  them.  All  NAVSUP  SPLICE  resident 
applications  are  being  written  for  TANDEM  6530  block  mode 
devices,  not  asynchronous,  scroll  mode  devices,  as  TELNET 
requires.  There  is  also  no  indication  that  any  NAVSUP 
application  will  be  re-written  to  support  such  devices, 
without  some  funding  source.  Some  TANDEM  software  packages, 
like  the  line  editor,  will  be  available  for  mail  interface. 

5.  DAAS/ AUTODIN  I  Access 

DAAS  is  an  acronym  for  the  Defense  Automatic 
Addressing  System.  AUTODIN  I  stands  for  the  Automated 
Digital  Network,  Number  I.  Together  they  represent  the 
primary  methods  used  today  to  transfer  military  standard 
(MILSTRIP)  documents  among  logistics  activities  (e.g., 
requisitions,  status,  etc.). 

An  activity  need  merely  batch  all  of  its  military 
standard  documents  together,  regardless  of  destination, 
append  appropriate  header  and  trailer  i n f o rm a t i o n  ,  88  and 
take  this  package  to  the  nearest  AUTODIN  access  point  for 
transmission.  The  AUTODIN  access  point  will  forward  the 
package  to  DAAS,  which  will  then  make  specific  document 

S^The  Joint  Chiefs  of  Staff,  Automatic  Digital  Network 
(AUTQDIN)  Operating  Procedures  JANAP  123,  of  March  1983  apply 


distribution  based  on  standard  activity  routing  identifiers. 
Alternatively,  a  site  may  specifically  code  tne  destination 
routing  identifier  for  each  transmission  package  in  order  to 
by-pass  DAAS  and  use  AUTODIN  I  for  direct  site  transmission. 

NAVSUP  stock  points  and  the  ICPs  are  directly 
interfaced  to  AUTODIN  I  for  both  DAAS  access  and  direct 
AUTODIN  I  site  t r an sm  i  s s i o n s  using  a  FMSO  developed  system 
called  On-Line  AUTODIN  (OLA).  This  system  is  PE  based  and, 
at  stock  points,  is  connected  to  the  Burroughs  hosts  via 
data  communications  lines  and  interfaces  with  MAPS  software 
(i.e.,  TDS/IDST)  for  package  preparation  and  subsequent 
document  distribution.  An  Uni  vac  494-to-OLA  interface 
ex  i  sts  at  the  ICPs  . 

Four  events  have  made  these  interfaces  no  longer 
desirable. 

1.  NAVSUP  wishes  to  phase  out  all  of  their  PE  equipment. 

2.  NAVSUP  wishes  to  phase  out  Burroughs  FEPs,  to  which 
OLA  interfaces . 

3.  The  ICP  Univac  hardware  is  being  replaced  by  IBM 
hard  ware . 

4.  DDN  appears  now  to  be  the  preferred  method  for 
computer- to-computer  data  transmission. 

As  a  result  of  these  events,  NAVSUP  directed  that  the  OLA 

system  be  phased  out  and  replaced  by  a  new  Defense  Data 

Access  ( 0 D A )  system  [Ref  109]. 

DDA  itself  is  planned  in  three  phases  [Ref.  110]. 
Phase  I  will  permit  the  passing  of  military  standard 
messages  in  JANAP  128  header  format  to  only  DAAS  and  receipt 


of  similarly  formatted  messages  from  DAAS.  The  FMSO 
documentation  appears  to  anticipate  passing  Burroughs 
prepared  messages  to  a  FDC  software  package  on  the  TANDEM 
for  further  distribution.  The  authors  anticipate  this  will 
be  the  FDC  CEM  software  and  CEM  must  handle  getting  them  to 
DAAS.  DDA  audit  capability  will  be  primarily  at  the  message 
level.  Altnough  SPLICE  complex  and  LCN  software  will  get 
transmission  packages  to  the  Burroughs  hosts,  a  MAPS 
software  package,  Transaction  Distribution  System  (TDS), 
will  perform  document  distribution.  The  JANAP  128 
formatting  of  messages  will  continue  to  be  done  on  Burroughs 
via  another  MAPS  software  product,  IDST. 

If  DAAS  is  on  the  DDN  at  the  time  DDA  Phase  I 
software  is  available  and  the  second  phase  of  the  SPLICE  DDN 
interface  is  also  available,  the  actual  message  passing  will 
be  accomplished  via  interoperable  DDN.  If  either  condition 
is  not  met,  some  number  of  SPLICE-DAAS  gateway  sites  will  be 
designated  and  traffic  sent  to  the  gateways  over  the  SPLICE 
DDN  closed  community  subnet.  The  SPLICE  gateway  sites  must 
then  be  interfaced  to  DAAS  itself  via  landlines  to  pass  on 
traffic. 89  DAAS  will  serve  as  the  stock  point  DDN-AUTODIN  I 
gateway,  where  this  function  is  still  required. 

89jhe  SPLICENet  proposal  recommends  use  of  the  TANDEM 
EXCHANGE  software  for  this  purpose,  permitting  a  SPLICE 
gateway  site  to  appear  as  an  IBM  2780/3780  Data  Transmission 
Terminal  using  the  BSC  point-to-point  protocol.  The  FMSO 
DDA  F0  mentions  nothing  about  this. 


Phase  II  of  00A  will  permit  transmission  of  military 
standard  traffic  to  other  than  DAAS  over  the  DDN.  DDA 
itself  will  determine  if  a  message  should  be  sent  to  DAAS  or 
directly  to  another  on-line  SPLICE  site.  Appropriate 
routing  information  and  messages  will  be  passed  to  CEM,  who 
will  handle  further  transmission.  Transaction  distribution 
facilities  will  be  moved  from  the  Burroughs  to  DDA  itself. 
Audit  capability  will  be  extended  to  include  batch,  message, 
and  transaction  levels. 

Regardless  of  whether  i  n tero per  a  b 1 e  DDN  access  is 
available  on  SPLICE,  CEM  will  pass  the  messages  directly  to 
the  addressed  SPLICE  site  using  the  SPLICE  EXPAND/X.25  line. 
The  correspond en t  receiving  CEM  will  then  pass  the  message 
to  the  remote  DDA  receiving  module.  If  DAAS  at  this  point 
is  on  DDN  directly,  the  gateways  will  be  eliminated. 

The  third  phase  of  DDA  will  include  DDA  direct 
access  to  the  two  ICPs,  as  well  as  full  DDN  community 
routing.  The  CEM  at  the  sending  site  will  determine  which 
path  to  take:  interoperable  DDN  or  CEM-to-CEM  over 
EXPAND/X.25.  All  ICP  destined  traffic  will  be  sent  over  the 
EXPAND/X.25  line  to  the  applicable  ICPNet  gateway. 

Having  addressed  the  various  requirements  for  inter¬ 
site  i n t e ro per ab i 1 i t y  and  how  SPLICE  can  satisfy  these 
r equ i r em en t s ,  the  area  of  benefits  can  now  be  addressed. 
Shore  based  i n t e r o p er ab i 1 i t y  will  provide  three  major 


b  en  e  f  i  t  s  : 


1.  improved  supply  information  to  the  user  community; 

2.  more  rapid  transmission  of  logistics  requirements  to 
the  suppl y  system ; 

3.  and  less  manual  intervention  required  to  perform 
logistics  missions. 

These  benefits  will  have  a  direct  affect  on  improving  fleet 
support . 

Existing  MAPS  RJE  activity  access  and  MAPS  RJE  site 
system  replacement  can  provide  the  following  benefits: 

1.  extension  of  the  life  of  existing  MAPS  RJE  equipment, 
thus  deferring  replacement  costs; 

2.  improved  terminal  processing  capabilities  at  the 
satellite  sites  after  SPLICE  equipment  is  installed  in 
terms  of  both  numbers  available  for  use  and  types 
supported . 

3.  improved  local  processing  capabilities  in  support  of 
local  applications  and  the  satellite's  ability  to  use 
SPLICE  complex  resident  applications,  D  D  A ,  and  DDN 
after  SPLICE  implementation. 

4.  the  ability  to  eliminate  card  processing  at  satellite 
sites  via  DDA ,  UCEPS,  and  other  source  data  automation 
efforts  after  SPLICE  implementation. 

5.  the  ability  to  isolate  satellite  MAPS  RJE  equipment 
and  operations  from  additional  disruption  during  SPAR 
transition  by  using  SPLICE  equipment.  The  additional 
disruption  would  be  in  the  form  of  hardware  and 
software  replacement  in  addition  to  host  procedure  and 
program  changes  that  SPAR  transition  will  require. 

These  benefits  can  directly  accrue  to  tide-water  fleet 

support  activities  enabling  them  to  provide  better  customer 

support  and  to  the  corporation  in  terms  of  better  geographic 

logistics  support . 


The  ability  to  access  DLA  systems/files  prior  to  their 
DON  interconnection  provides  two  benefits  to  stock  point 
users: 

1.  the  ability  to  obtain  better  management  information  on 
contract  initiatives,  DLA  stock  numbers,  replenishment 
actions,  and  supply  support  actions; 

2.  the  ability  to  more  rapidly  input  update  or  change 
actions  directly  into  the  DLA  system. 

Both  of  these  benefits  will  assist  stock  point  retail 

c ommod i t y / i tem  managers  who  are  responsiDle  for  maintaining 

retail  stockage  levels  in  support  of  fleet  customers. 

Both  DDN  and  DAAS/AUTODIN  I  access  will  provide 

similar  benefits  to  the  corporation,  the  most  important 

being  the  ability  to  el ec tron ic al 1 y  transmit  and  receive 

information.  The  DAAS/AUTODIN  I  access  provides  this 

ability  in  the  interim  to  all  DOD  activities  being  on  DDN, 

while  also  providing  document  distribution  services,  if 

desired.  The  DDN  access  provides  the  long-term  means  by 

which  the  corporation  will  accomplish  horizontal  and 

vertical  system  integration,  establish  shipboard  to  shore 

logistic  system  integration,  implement  a  corporate 

electronic  mail  system,  and  permit  users  and  processes  to 

c  omm  un i c  a  te  . 

The  same  comments  made  concerning  the  need  for  intra¬ 
site  connectivity  migration  to  SPAR  apply  here  to  inter-site 
i n tero per ab i 1 i ty .  Many  of  the  systems  mentioned  within  this 
section  will  remain  in  place  for  the  entire  SPLICE  life 
cycle  and  later  be  replaced  by  systems  performing  similar 


functions  for  which  the  interface  requirements  will  remain. 
While  SPLICE  is  present,  there  should  be  no  neea  to  migrate 
or  be  concerned  with  inter-site  i  n tero per ab  i  1  i  ty  :  SPLICE 
will  provide  for  it.  When  the  time  comes  to  prepare  for 
SPLICE  replacement  within  SPAR,  the  existing  interfaces  ana 
lessons  learned  from  SPLICE  should  be  invaluable  tools  upon 
which  to  base  replacement  system  functional  specifications. 

Intra-site  i n t e r o per ab  i  1  i  t y  supports  or  is  supported 
by  the  following  proposed  SPLICE  objectives:  6,  8,  10,  12, 
15,  16,  19,  20,  21,  22,  23,  25,  29,  32,  33,  and  41. 

The  authors  would  like  to  recommend  the  following  for 
consideration  in  this  area: 

1.  Initiate  a  requirements  study  to  determine  what  are 
existing  and  planned  local  data  communications 
interfaces  to  stock  points,  that  DDN  may/will  not 
accommodate.  Incorporate  the  results  into  SPLICE 
project  plans  and  SPLICENet  proposal. 

2.  Revise  the  FMSO  SPLICE  Phase  II  design  and  the 
SPLICENet  proposal  to  account  for  some  Burroughs  MAPS 
RJE  equipment  being  interfaced  directly  to  SPLICE. 

3.  Develop  a  plan  to  replace  all  Burroughs  MAPS  RJE 
equipment  so  interfaced  before  SPAR  implementation. 

If  price  remains  an  obstacle,  consider  substituting 
smaller  TANDEM  systems  or  components  (i.e.,  EXT  or  any 
of  several  other  smaller  entry  level  systems  that  will 
be  announced  by  TANDEM  this  year).  This  is 
particularly  feasible  at  small  MAPS  RJE  sites,  that  do 
little  more  today  than  terminal  concentration, 
transmit  input  documents,  perform  local  programming 
and  for  whom  the  SPLICE  MAPS  site  benchmark  has  little 
practical  workload  bearing  (i.e.,  SUBASE  Pearl 
Harbor ) . 

4.  Eliminate  the  need  for  satellite  card  processing  by 
extending  NAVSUP  card  elimination  efforts  (i.e.,  SDA 
and  UCEPS)  and  DDA  to  satellite  sites  on  SPLICE. 

Then,  eliminate  the  card  reader/punch  from  the  SPLICE 


contract  and  the  requirement  for  remote  card  equipment 
support. 

5.  Attempt  to  reduce  user  input  requirements  to  initiate 
DLA  access  to  only  menu  selections  and  security  sign- 
ons.  The  system  interface  concept  reviewed  by  tne 
authors  appears  feasible  but  the  details  must  be 
geared  to  the  GS  4/5  Supply  Clerk  for  use,  not  an  IBM 
systems  programmer. 

6.  Obtain  a  commitment  from  TANDEM  via  FDC  to  support 
standard  X.25  under  EXPAND.  Although  the  Defense 
Communications  Agency  will  attempt  to  block  this, 
retain  the  basic  X.25  lines  until  then. 90 

7.  Ensure  that  FDC  plans  for  DON  access  under  SPLICE  Net 
will  not  reduce  SPLICE'S  ability  to  use  existing  or 
planned  off-the-shelf  TANDEM  packages,  such  as 
TRANSFER  or  PS  MAIL,  the  future  TANDEM  SQL  product,  or 
the  future  TANDEM  products  which  will  address 
interconnecting  electronic  mail  systems. 

8.  Develop  an  application  access  support  plan  to  SPLICE 
for  non-SPLICE  systems  and  users.  Include  in  tnis 
plan,  what  systems,  files,  and  transactions  each 
external  user  will  be  authorized  by  NAVSUP  to  use  and 
the  1 ine/ network/gateway/dev  ice  that  each  will  be 
using.  This  plan  should  then  be  given  to 

F M S 0 / FDC/DLA/NAVMASSO  to  implement,  where  possible, 
and  require  feedback  to  NAVSUP  as  to  what  is  required 
of  the  user  to  provide  the  requested  access  if  not 
immediately  possible.  91 

9.  Ensure  that  FMSO  and  FDC  are  both  working  from  the 
same  set  of  design  plans  for  DDA,  particularly  in 
terms  of  internal  site  interface.  From  the  limited 
documentation  held  by  the  authors,  it  is  unclear  if 
FMSO  is  aware  of  the  details  of  SPLICENet  in  the  area 
of  DDN/DAAS  interface.  Perhaps  the  interface  to  and 
from  DDA  to  CEM  will  be  as  transparent  as  the  FMSO 

90co nv er sa t i o n s  with  mid-level  Defense  Communications 
Agency  personnel  indicated  that  they  plan  on  removing  the 
oasic  X.25  lines  from  SPLICE  sites  as  soon  as  TCP/IP  is 
implemented  on  SPLICE  or  until  SPLICE'S  next  DDN  waiver 
expires,  whichever  is  sooner. 

91of  particular  interest  here  is  the  DDN  user  on  a  dumb 
terminal  who  "TN's"  to  a  SPLICE  site  and  finds  that  no 
logistics  services  are  available  to  him  since  they  were  all 
designed  for  more  intelligent  block  mode  devices. 


VIII.  SHIPBOARD  TELECOMMUNICATIONS  INTEROPERABILITY 


A.  CHAPTER  OVERVIEW 

This  chapter  will  address  the  area  of  snipooard  to  shore 
9 s taD 1 i s hm en t  i n t e r o per ab  i  1 i t y  in  terms  of 
telecommunications  and  the  Shipboard  Nontactical  Automated 
Data  Processing  (SNAP)  programs.  Two  of  the  sections 
presented,  Background  SNAP  I  and  Background  SNAP  II,  are 
provided  for  background  information,  if  the  reader  is 
unfamiliar  with  the  SNAP  systems  that  are  being  installed  on 
all  major  ships  and  their  application  areas.  If  the  reader 
is  familiar  with  the  functions  of  SNAP  I  and  II,  bypassing 
these  background  sections  is  recommended.  The  Naval  Air 
Logistics  Command  Management  Information  System  (NALCOMIS) 
is  also  discussed  in  this  chapter  as  it  is  being  deployed  on 
ships  for  aircraft  maintenance  and  repair  at  the  afloat  IMA 
level.  NALCOMIS  runs  on  the  same  computer  hardware  as  other 
SNAP  I  applications,  the  Honeywell  DPS6  series. 

The  authors  intent  in  this  chapter  is  to  show  how  the 
"great  leap  forward"  in  automating  the  shipboard  environment 
would  benefit  from  interfacing  via  telecommunications  to 
SPLICE  and  from  SPLICE  to  the  outside  world,  ratner  than  the 
mailed  or  hand  carried  magnetic  tape,  card  output,  and 
AUTODIN  I  system  interfaces  currently  planned  for  use  while 
ships  are  in  port. 


8.  BACKGROUND  SNAP  I 

SNAP  I  is  planned  for  use  in  selected  shore 
establishments  and  on  large  snips.  The  primary  purpose  of 
SNAP  I  is  a  replacement  system  for  the  obsolete  Univac  U1500 
computer  systems  currently  installed  on  ships  of  type  CV, 

CVN ,  AFS,  AS,  AD,  AR,  LPH ,  and  LHA.  The  Univac  U1500  is  a 
batch  tape  oriented  system  that  is  early  I960'  s  technology. 
This  system  supported  financial,  inventory,  requisition,  and 
intermediate  maintenance  management  system  applications. 

The  SNAP  I  computer  is  based  on  late  1970's  technology, 
manufactured  by  Honeywell,  and  designated  as  a  DPS6 
(series).  The  SNAP  I  system  is  to  give  the  above  mentioned 
large  combatants  and  selected  shore  support  activities  a 
real  time,  disk,  and  CRT  oriented  ADP  system.  The  overall 
concept  of  the  new  system  is  detailed  in  SNAP  II  Management 
Guide  [Ref.  Ill]  as: 

To  improve  fleet  readiness  and  provide  a  standard 
automated  information  system  ( A I S )  to  be  used  by  all 
fleet  operational  and  direct  units,  afloat  and  ashore. 
Inherent  to  this  concept  is  the  premise  that  all  SNAP 
functional  requirements,  and  particularly  the  machine 
interface  r eq u  i  r em en t s  ,  are  identical  for  all  ship 
types. 

SNAP  I  will  provide  ADP  support  for  not  only  the  batch 
oriented  jobs  that  the  U  1  5 0 0 s  once  performed,  including  the 
movement  of  these  processes  to  disk,  it  will  also  convert 
many  of  these  applications  to  an  on-line  CRT  orientation. 

In  addition,  it  will  automate  many  of  the  current  manual 
administrative  and  logistic  shipboard  functions,  thereby 
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reducing  the  paperwork  burden  on  shipboard  and  staff 
personnel  and  allowing  them  to  concentrate  more  on  tne 
quality  of  the  information  that  is  required  to  be  provided 
to  shore  establishment  commands. 

SNAP  I  is  divided  into  to  five  functional  areas  for 
automation.  These  ares  are:  Adm  i  n s tr a t i o n  (ADM), 
Intermediate  Maintenance  Management  System  (IMMS),  Ownship 
Maintenance  Management  System  (OMMS),  Source  Data  System 
Afloat  (SDSA),  and  Shipboard  Uniform  Automated  Data 
Processing  (SUADPS).  A  brief  listing  of  the  functions 
provided  in  each  area  follows: 

1.  ADM  -  maintains  management  of  Shipboard  personnel 
assignment,  career  development  and  retention,  health/ 
administration/morale  subsystem  management,  personnel 
qualification  management,  retention  program 
management,  ship's  bill  management,  security  force 
management,  schools  management,  visitor  control 
management,  and  ad  hoc  query. 

2.  IMMS  -  maintains  an  automated  Current  Ship’s 
Maintenance  Project  (CSMP)  file  at  the  Intermediate 
Maintenance  Level  (IMA)  which  provides  the  following 
functions:  plan  work  requests,  screen  work  requests, 
create  work  packages,  track  job  progress,  schedule 
jobs  and  key  events,  validate  maintenance  requests, 
and  ad  hoc  query. 

3.  OMMS  -  will  provide  the  following  functions: 
management  of  current  ship's  maintenance  project 
(CSMP),  trouble  log  processing,  equipment 

con f ig ura t ion  and  logistics  support,  work  package 
processing,  management  reports,  CSMP  reporting 
process,  and  subsystem  manager  functions. 

4.  SDSA  -  is  designed  to  provide  the  following  functions 
disbursing  and  personnel  area  administrative  and  pay 
event  reporting,  pay  and  fiscal  management,  SDSA 
system  management  information. 

5.  SUADPS  -  is  to  provide  the  following  functions:  on¬ 
line  data  entry/error  processing,  master  record  file 


query,  substitute  information,  interactive  material 
request,  picking  tickets,  Direct  Turnover  Over  (DTO) 
requisition  release,  warehouse  processing, 
Consolidated  Shipboard  Allowance  List  (COSAL) 
processing,  supply  effectiveness  reporting,  financial 
man ag emen t/ B udg e t  Optar  reporting,  and  Glooal 
reo  rd  er / of f 1 oad  . 

From  this  extensive  listing  it  can  be  seen  that  SNAP  I  is 
designed  to  automate  many  of  those  shipboard  administrative 
and  logistic  functions  that  have  been  performed  manually  or 
in  a  batch  mode  in  the  past. 

All  interfacing  to  and  from  this  shipboard  systems  is 
planned  to  be  accomplished  via  magnetic  tapes,  puncned 
cards,  or  through  a  paper  tape  medium  to/from  the  AUTODIN  I 
system.  Currently,  the  SNAP  activities  which  require  an 
automated  interface  with  external  systems  are  as  follows: 
submission  of  Material  Maintenance  Management  System  ( 3 - M ) 
data  (OPNAV  4/9Q/2K),  receipt  of  bulk  Coordinated  Shipboard 
Maintenance  Project  (CSMP)  input,  submission  of  requisition 
and  budget  OPTAR  data,  receipt  of  requisition  status  data, 
receipt  of  full  and  supplemental  COSAL  update  tapes,  and 
automated  Allowance  Parts  Lists  (APL)  deletion  and 
reestablishment.  A  more  in  depth  discussion  of  external 
interfaces  is  provided  in  [Ref.  112]. 

Even  the  currently  planned  off  ship  interface  methods 
listed  above  are  seen  as  major  improvements  in  the  accuracy 
and  timeliness  of  configuration  and  logistics  data  movement 
If  a  more  s t a t e- o f - t h e- ar t  interface  method  was  available, 
SNAP  I  sponsors  would  be  anxious  to  pursue  it. 
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C.  SNAP  I  SUPPORT  APPLICATION  INTERFACES 

The  currently  planned  SNAP  I  to  shore  establishment 
interfaces  require  that  when  a  ship  is  in  port  a  physical 
transfer  of  tape  media,  punched  cards,  or  paper  forms  oe 
routinely  done  in  order  to  transmit  or  receive  any 
information.  An  example  from  the  requisition  input  area 
will  be  used  to  demonstrate  this. 

The  submission  of  requisitions  into  the  supply  system  is 
now  accomplished  in  a  number  of  ways.  First,  submission  may 
be  accomplished  by  physically  routing  a  tape  of  MILSTRIP 
formatted,  card  image  requisitions  to  the  local  NSC  for 
processing.  Such  a  tape  submission  is  not  only  wasteful  of 
physical  sailor  effort  in  delivery,  it  wastes  NSC  manpower 
in  handling,  and  must  also  be  converted  before  the  NSC's  can 
read  the  data,  since  the  data  formats  are  in  many  cases 
incompatible.  This  can  result  in  requisition  processing 
delays  of  up  to  three  days. 

In  other  cases,  punched  cards  are  used  as  the  primary 
means  of  delivering  requisitions  to  the  NSCs.  Besides  being 
equally  wasteful  of  manpower  in  performing  delivery,  card 
processing  is  obsolete  technology  and  is  wasteful  of  both 
shipboard  and  NSC  customer  service  and  operations  manpower, 
particularly  since  this  method  requires  very  old  card 
equipment  to  be  maintained  and  made  to  function  properly. 

In  the  case  of  high  priority  requisitions,  a  manual 
paper  requisition  form  is  often  prepared  and  hand  carried  to 


the  NSC,  where  it  must  be  data  transcribed  prior  to 
processing.  This  process  in  not  only  wasteful  of  shipboard 
personnel  time,  it  requires  duplicate  data  entry  efforts, 
thereby  adding  to  the  possibility  of  error  introduction. 

Several  of  the  NSC's  have  developed  on-line  capabilities 
to  input  requisitions  via  separate  telecommunications 
terminals  installed  on  ships  while  they  are  in  port.  For 
example,  NSC  San  Diego  uses  what  it  calls  the  Fleet  On-Line 
Inquiry  and  Requisitioning  System.  This  system  consists  of 
a  12"  monitor  and  processor  with  al pha/ numer  ic  keyboard 
(i.e.,  a  Burroughs  compatible  CRT)  and  an  80  col  urn n  printer 
connected  into  their  Burroughs  host  via  telecommunications. 
The  telecommunications  hookup  is  a  2-wire  single  port  modem 
and  a  registered  connecting  device.  Since  this  system 
requires  duplicate  data  entry  (i.e.,  once  on  the  shipboard 
system  and  once  on  the  NSC  terminal)  and  human  t r an  sc r i p t  i  o n 
of  computer  created  requisitions,  only  high  priority 
requisitions  are  processed  in  this  way.  This  system  also 
allows  users  to  query  local  stock  availability,  obtain 
requisition  status,  input  requisition  modifiers,  and  perform 
requisition  follow  ups. 

The  system  installed  at  San  Diego  and  similar  systems 
installed  at  other  NSCs  do  perform  the  job  of  allowing  fleet 
units  to  input  h i g h- pr  i  o r  i  t y  requirements  and  receive  status 
of  the  requisitions  submitted  to  the  NSC  on  a  real  time 
basis.  However,  it  requires  additional  telecommunications 


workload  for  tne  NSC's  Burroughs  hosts  and  it  nas  done 
nothing  to  improve  the  submission  of  large  requisition  drops 
(  i . e. ,  tapes  or  card  s) . 

What  is  required  in  this  area,  as  well  as  in  all  other 
shore  establishment  data  interface  areas,  is  to  nave  an  on¬ 
line,  high  capacity  interface  capability  between  the  SNAP  I 
computer  systems  and  the  logistics  system  to  obtain  access 
to  the  NSCs  and  otner  shore  based  facilities.  In  the 
opinion  of  the  authors,  the  SPLICE  system,  particularly  with 
SPLICENet,  can  not  only  handle  (or  expand)  the  existing 
number  of  shipboard  single  terminal  interconnections  to  the 
NSCs,  but  it  can  also  provide  other  system  access  (non-NSC), 
as  well  as  higher  capacity  links  or  multiple  links  to  enable 
the  passing  of  large  data  packages. 

The  problem  of  shipboard  interface  to  SPLICE  is  two 
prong ed.  First,  shipboard  units  have  to  be  provided  access 
to  a  SPLICE  site.  Second,  mechanisms  must  be  available  at 
the  SPLICE  sites  to  allow  for  sh i pboard - to- sho r e 
establishment  interoperability  and  permanent  account  space 
or  mailbox  storage. 

The  changes  required  in  the  SNAP  I  system  to  provide 
access  or  establish  SPLICE  system  connectivity  were  detailed 
in  a  meeting  held  at  FMSO  on  2  August  1984  and  they  are  as 
follows: 

1.  addition  of  a  Synchronous  Communications  Line  Adapter 
board,  to  be  resident  on  the  Honeywell  processor 
requiring  data  communication  access  (requires  a  SNAP 
contract  modification). 


2  .  addition  of  the  PF/3271  (BSC)  software  package,  to  be 
resident  on  the  Honeywell  processor  requiring  data 
communications  access  (also  requires  a  SNAP  contract 
mod i f icat ion) . 

3.  Government  programming  of  "user  exits"  from  the 
PF/3271  software  (provides  a  presentation  layer  for 
the  application  process  to  pass  data  sets). 

4.  Training  of  FMSO  or  NAVMASSO  environmental  personnel 
in  the  above  so  that  they  can  program  the  "user 
exits." 

In  addition  to  these  enhancements  to  the  SNAP  I  system, 
the  SPLICE  system  will  require  "peer"  presentation  and 
application  processes  to  interface  with  the  SNAP  I 
computers,  as  well  as  6100  c ommun  i  ca t  i  on s  subsystem  ports 
available,  capable  of  dealing  with  BISYNC  lines.  This 
higher  speed  land  line  interface  also  requires  the  use  of 
quality,  dedicated  phone  lines,  with  synchronous  modems  at 
either  end,  for  each  SNAP  system  on  the  pier. 

If  this  BISYNC  dedicated  line  service  cannot  be  made 
available  for  pier-side  use,  then  the  SNAP  I  sites  could 
al  ternativel  y  implement  a  dial-up  modem  option  to  interface 
to  SPLICE.  SNAP  I  Honeywell  systems  can  be  directly 
connected  to  a  Rixon  modem  (i.e.,  R212A)  to  accomplish  this 
(available  from  the  SNAP  I  contract)  with  user  written 
asynchronous  interface  software  to  permit  the  Honeywell 
system  console  or  a  designated  terminal  to  act  as  a  remote 
asynchronous  terminal  to  the  SPLICE  host.  No  off-the-shelf 
software  package  was  located  by  the  authors  which  could 
perform  this  function. 


A  second  alternative  would  be  the  use  of  one  of  the  S N A P 
I  system's  smart  terminals/PCs  (i.e.,  Z-150's)  to  download 
data  to  be  transmitted  to  the  PC's  disk  from  the  Honeywell 
system,  using  a  Honeywell  provided  software  package  (i.e., 
Microsystem  VIP  Emulation).  When  all  data  is  on  the  PC,  the 
user  would  shift  to  a  stand-alone  PC  operating  mode;  dial-up 
the  local  SPLICE  site  using  a  local  phone  1 i n e/ asy nc hr o no u s 
communications  package  and  sign-on  to  SPLICE  via  SAS  to 
process  transactions  or  pass  data  as  required. 

Assuming  that  SPLICE  system  connectivity  has  been 
provided  at  some  SPLICE  site  via  one  of  the  methods  proposed 
above,  the  second  problem,  providing  shi pboard-to- shore 
establishment  interoperability  can  now  be  addressed.  There 
are  three  aspects  to  this  problem:  local  processing,  AUTODIN 
interface,  and  DON  interface. 

Once  the  shipboard  user  has  passed  security  and  signed 
onto  a  SPLICE  site,  what  can  be  processed  locally  via  a  SNAP 
I  terminal  or  process  will  depend  on  the  processing 
functions  performed  at  the  SPLICE  site.  In  the  case  of  a 
NSC,  a  full  range  of  logistics  functions  as  well  as  other 
system  interfaces  may  be  locally  available.  In  the  case  of 
a  user  signing  on  to  a  NARDAC  or  NARDAF  SPLICE  site  not 
running  UAOPS-SP,  the  user  might  have  to  use  SPLICENet  to 
access  a  SPLICE  site  processing  UADPS-SP  to  obtain  full 
logistics  functionality.  Assuming  that  the  user  has 


signed-on  to  a  logistics  capable  site,  at  least  the 
following  processing  may  be  accomplished: 

1.  input  of  high  priority  requisitions. 

2.  input  of  bulk  requisition  packages  generated  directly 
from  the  SUADPS-RT  system  onboard  the  ships.  This 
would  eliminate  the  delay  and  wasted  man  hours  of 
having  to  convert  magnetic  tapes  to  a  format  capaole 
of  being  read  by  the  NSC's  system,  reduce  the  need  for 
obsolete  card  equipment  on  both  systems,  and  would 
also  eliminate  the  need  to  enter  a  requisition  more 
than  once. 

3.  requisition  status,  stock  status,  stock  management 
data  inquiries  using  either  SPLICE  Burroughs  pass 
through  or  the  SPLICE  resident  applications  including 
replicated  files.  This  would  reduce  the  number  of 
phone  calls  that  are  received  at  the  NSCs  for  status 
of  parts  ordered,  requests  for  stock  management  data, 
and  requests  for  current  stock  assets  on-hand. 

4.  receive  status  back  for  inputs  submitted  for  direct 
input  to  SNAP  I  processes. 

5.  use  of  either  SPLICE  TANDEM  TRANSFER/PS  MAIL  and 
TANDEM  editors  or  DDN  mail  and  editors. 

6.  upload  or  download  of  files  to  and  from  the  SPLICE 
system.  These  files  could  be  local  status  outputs 
from  NSC  batch  processes,  a  series  of  user  queries 
captured  to  disk,  MTIS  inquiries,  or  similar  actions. 

The  second  part  of  s h i pboard - to- sho r e  establishment 
i n t e ro per ab i 1 i t y  concerns  AUTODIN  I  processing.  Today 
shipboard  units  receive  the  majority  of  their  requisition 
status  via  AUTODIN  I  cards  or  tapes  which  must  be  input  to 
SNAP  I  processes  on  a  batch  basis.  The  following  describes 
how  the  status  updates  of  requisitions  could  be  forwarded  to 
the  ships  in  a  more  timely  manner  and  the  amount  of  Naval 
message  traffic  generated  for  status  of  high  priority 
requisitions  could  be  reduced  using  SPLICE: 


1.  A  system  that  is  in  development  now  will  permit  both 
SNAP  I  and  SNAP  II  systems  to  receive  their  logistics 
M I LSTRI P  messages  from  the  AUTODIN  system  in  an  on¬ 
line  manner  instead  of  the  current  hard  copy  formats, 
if  certain  changes  are  made.  As  previously  discussed, 
00A  is  a  NAVSUP  planned,  major  replacement  of  the 
existing  PE  based  On-Line  AUTOOIN  (OLA)  system  being 
used  at  stock  points.  When  DDA  is  implemented,  all 
stock  points  and  ICPs,  as  well  as  any  other  SPLICE 
site  which  have  implemented  DDA,  could  have  the 
capability  to  interface  with  other  sites  for  passing 
and  receiving  logistics  traffic  directly  or  using  the 
DAAS  system  as  a  switch  between  AUTODIN  I  and  DON. 

2.  SPLICE  is  to  be  implemented  at  all  the  NARDACs  and 
NARDAFs.  If  NAVDAC  would  agree  and  be  funded  to  have 
the  NARDACs  and  NARDAFs  to  become  the  DON  hosts  for 
shipboard  users  via  their  SPLICE  systems,  the 
following  could  occur:  DDA  could  be  implemented  at 
each  NARDAC  and  NARDAF;  DAAS  would  record  each  ships 
address  as  being  at  an  appropr  iatel y  located  NARDAC  or 
NARDAF  and  forward  all  AUTODIN  traffic  for  the  units 
there;  DDA  would  process  DAAS  inputs  for  the  ships  and 
segregate  transmissions  into  separate  shipboard 
accounts  or  mailboxes  at  the  NARDACs  or  NARDAFs. 

Using  the  download  procedures  described  previously 
under  local  processing,  these  files  could  be  received 
shipboard  and  input  into  SNAP  I.  Ships  could  also 
reverse  the  process  and  send  their  traffic  out  over 
DDA  to  DAAS  and  then  through  AUTODIN  I. 

As  previously  indicated,  the  authors  envision  a  system 
that  would  allow  the  users  to  be  either  directly  connected 
or  dial-up  connected  to  their  host  NARDAC  or  NARDAF  SPLICE 
system  and  be  able  to  access  their  pre-established  account 
or  mail  box  to  pull  down  existing  traffic  or  input  new 
traffic.  In  this  way,  the  process  of  receiving  AUTODIN 
traffic  via  mail  or  tape  in  card  format  or  Naval  message 
format  could  be  eliminated  during  the  time  a  ship  is  in  port 
or  in  a  local  operations  status. 

The  final  area  of  s h i pbo a rd - t o- s ho r e  establishment 
interoperability  is  DON  access  and  usage  itself.  There  are 


three  aspects  to  this.  First,  the  shipboard  units  m  u  s  t  have 
a  shore-based  DDN  host  site  available  to  serve  as  tneir  data 
repository  when  they  are  not  in  port.  The  authors  have 
recommended  the  use  of  SPLICE  NARDACs  and  NARDAFs  sites  for 
this  role.  Second,  once  the  ship  has  signed  on  to  a  SPLICE 
node,  it  must  be  able  to  have  available  to  it  the  full  range 
of  DON  protocols  for  interoperability  outside  of  the 
logistics  community.  SPLICE  plans  to  provide  this  under 
SPLICENet.  Third,  the  shipboard  user  should  also  have 
access  to  portions  of  the  SPLICENet  which  will  provide 
interface  among  NAVSUP  customers  through  SPLICE  TANDEM 
EXPAND/X.25  facilities,  and  which  also  provides  interface  to 
ICPNet  and  DLANet. 

If  the  above  m ul t i - pr o ng ed  proposal  were  adopted,  a 
method  would  exist  for  inputting  any  shipboard  data  to  any 
shorebase  location  via  SPLICENet  (  i .  e .  ,  providing  access  to 
DDN,  DDA,  ICPNet,  and  DLANet)  or  vice  versa.  With  this  in 
place,  other  shipboard  systems  could  also  take  full 
advantage  of  it.  For  example,  shipboard  financial  documents 
and  returns  must  be  submitted  to  and  interfaced  to  IDAFMS. 
This  proposed  NARDAC  and  NARDAF  DDA  interface  or  the  fully 
DOQ  interoperable  SPLICE  DDN  interface  using  FTP  could  be 
used  to  meet  this  shipboard  interface  requirement  to  IDAFMS. 

The  SDSA  project,  in  support  of  the  SDSA  subsystem  tnat 
is  to  be  run  on  the  SNAP  I  computer,  is  the  functional 
sponsor  that  has  most  aggressively  pursued  the  ability  ui  a 
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ship  in  port  to  be  able  to  transfer  its  pay  and  personnel 
data  to  the  snore  based  SDSA  subsystem,  in  a  real-time  moae. 
Data  submission  is  currently  aone  by  magnetic  tape.  Tne 
delays  caused  by  tne  mailing  of  the  tapes  becomes  very 
wasteful  in  the  amount  of  transactions  that  must  oe 
overridden  on  LES’s  by  the  local  disbursing  officers.  The 
average  delay  from  a  mailing  is  13  days  and  2  7  -A  of  the 
changes  submitted  must  be  overridden  by  the  local  disbursing 
officers  [Ref.  113]. 

The  direction  that  the  SDSA  program  manager  is  moving 
toward  is  that  of  using  a  phone  link  to  some  unspecified  DON 
connection  while  the  ship  is  in  port  to  reach  the  two  end 
activities,  the  Naval  Finance  Center  Cleveland  and  the  Naval 
Personnel  Command,  Washington.  This  proposal  provides  that 
"unspecified"  connection. 

Since  a  connection  to  the  DDN  can  be  made  with  the 
SPLICE  computer,  the  proposed  interface  would  reduce  tne 
need  of  the  extra  line  to  service  solely  the  SDSA  input  from 
the  SNAP  I  computer.  Since  the  ship  can  support  only  so 
many  phone  lines,  it  makes  sense  to  combine  all  the 
electronic  output  into  one  line  and  machine.  The  connection 
should  be  from  the  SNAP  I  computer  to  a  local  SPLICE  system. 
SPLICE  in  this  case  would  be  used  as  a  connection  to  the  DDN 
for  transfer  of  the  information  from  the  ship  to  the 
receiving  activities  DDN  files,  account,  or  mail  box.  If 
on-line  SOSA  shipboard  terminal  access  is  also  desired,  the 


DDN  TELNET  protocol  will  be  available  from  SPLICE  to  permit 
snipooard  users  the  ability  to  “TN"  to  the  S  D  S  A  snorea  oases 
nost(s)  ana  sign  on. 

The  ships  could  also  use  the  SPLICE  connection  ana 
SPLlCENet  to  logon  to  ICPNet  and  download  CGSAL  Changes 
and/or  update  the  ship's  configuration  information  on  SPCC's 
Weapons  System  File  (WSF).  The  processing  of  COSAL  changes 
and  the  submitting  of  ships  configuration  changes  had  been  a 
manual  process  until  the  installation  of  the  SNAP  I 
computers.  This  process  is  now  served  by  an  automated  data 
base  onboard  ship  that  is  updated  periodically  Dy  magnetic 
tape  input.  The  inputs  to  this  process  come  from  tne  WSF 
maintained  by  SPCC. 

Since  SPCC  is  a  user  of  SPLlCENet,  it  seems  only 
sensible  that  instead  of  waiting  for  a  quarterly  tape  dump 
of  COSAL  changes  to  be  mailed  to  the  ship,  an  on-line 
facility  using  SPLICE  as  the  backbone  could  be  utilized  to 
forward  these  changes.  In  this  way  a  ship  upon  arrival  in 
port  could  connect  to  the  local  SPLICE  site  through  tne 
proposed  shipboard  SPLICE  interface  and  then  on  to  the  DDN 
to  connect  to  the  SPLICE  computer  at  SPCC  from  which  ICPNet 
access  is  available.  The  ship  could  then  download  its  COSAL 
changes  to  the  remote  SPLICE  site,  FTP  applicable  changes  to 
its  local  SPLICE  DDN  host,  and  finally  download  the  changes 
to  its  SNAP  system  or  intelligent  terminal.  In  this  manner 
the  shipboard  user  could  receive  his  COSAL  cnanges  that 


would  be  neld  in  read-only  files  at  SPCC,  waiting  for  him  tc 
retrieve  them.  This  seems  to  tne  authors  to  be  a  more 
expedient  and  efficient  method  for  disseminating  the 
critical  logistical  support  information  that  is  contained  ir 
the  quarterly  changes  tapes. 

All  of  the  above  systems  are  looking  at  either  having 
their  own  snipooard  interface  or  terminals  to  transmit 
information  to  and  from  ships.  By  using  a  single  SPLICE 
interconnection,  the  need  for  multiple  lines  to  the  ship  and 
the  confusion  and  trouble  of  dealing  with  them  would  be 
reduced  or  eliminated. 

The  feasibility  of  using  such  an  approach  for  shipboard 
connectivity  has  already  been  demonstrated.  Currently,  a 
Submarine  tender  located  in  Europe  is  using  MINET,  with  a 
link  to  the  DDN  and  a  Bulk  Media  Terminal,  to  transfer 
machine  readable  information  across  the  packet  networks 
[Ref.  114],  In  this  case  the  tender  is  sending  requisitions 
to  a  stateside  DON  host,  with  the  Poseidon  Material  Office, 
Atlantic  (PMOLANT)  as  the  intended  recipient.  PMOLANT  then 
accesses  the  DDN  host  via  a  dial-up  to  a  TAC  from 
Charleston,  S.C.  and  receives  the  requisitions  or  sends 
status  by  use  of  the  mail  facility  on  the  DDN. 

Justification  for  this  method  lies  in  the  reduction  of 
system  handling  time  and  of  transmission  delays  which  would 
occur  using  the  AUTODIN  system  or  the  extensive  manual 
effort  required  for  message  transmission  alone.  With  this 


system,  requisitions  can  be  sent  and  received  in  as  little 
as  6  hours  from  start  to  finish  [Ref.  114].  The  proposed 
SPLICE  implementation  could  provide  similar  services  and 
benefits  to  all  SNAP  I  users. 

The  final  area  that  will  be  addressed  is  how  SNAP  I 
tactically  supports  or  can  be  made  to  better  support  the 
proposed  SPLICE  objectives,  thereby  supporting  previously 
presented  corporate  and  project  goals  and  strategies.  SNAP 
I  directly  supports  and/or  is  supported  by  the  following 
SPLICE  project  objectives:  12,  15,  16,  19,  21,  22,  33,  and 
35. 

There  are  several  r ec omm end  a t i o n s  the  authors  have  for 
possible  enhancements  to  SPLICE/SNAP  I  that  will  enable  them 
to  provide  greater  support  or  benefit  to  the  corporation  and 
to  the  Navy  as  a  whole: 

1.  Investigate  and  test  the  software/ hardware  to 
support  the  SNAP  I  telecommunications  interface  to 
the  SPLICE  system  to  allow  for  both  on-line 
interaction  and  bulk  file  transfer  to  the  logistics 
system  using  the  synchronous  interface. 

2.  Investigate  and  test  the  software  to  support  the  SNAP 
I  user  interfaces  to  the  SPLICE  system  via  the 
Honeywell  host  itself  or  a  smart  terminal/PC  installed 
on  SNAP  I  ships  and  a  modem  using  an  asynchronous 
line.  Either  of  these  interfaces  would  provide  for 
both  shipboard  on-line  inquiry  and  bulk  file  transfer 
capabilities  using  SPLICE  or  other  supported  terminal 
emulation  software  such  as  the  MicroGate  6530. 

3.  Investigate  the  possibility  for  SPLICE  providing  the 
gateway  to  DON  for  shipboard  users  using  NARDACs  and 
NAROAFs  as  hosts.  This  would  provide  shipboard  access 
and  system  interoperability  necessary  for  systems  such 
SOSA,  IDAFMS,  and  COSAL  updates. 


4.  Investigate  the  possibility  of  SPLICE  being  the 
shipboard  access  to  AUTODIN  I  via  a  DDA  interface  at 
the  NARDACs  and  NARDAFs.  This  includes  the 
establishment  of  SNAP  I  ship  DDN  accounts  or 
electronic  mail  boxes  there.  This  would  allow  all 
SPLICE  users  and  DDN  users  the  ability  to  send 
information  electronically  to  the  ships.  Data  such  as 
COSAL  updates,  Disbursing,  Financial,  and  Personnel 
data  could  then  be  passed  in  this  manner  on-line. 

5.  See  the  proposals  in  Chapter  IV  for  shipboard 
interfaces  to  SPLICE  for  use  of  REP  FILES  and  MTIS 
processing  and  the  Chapter  VI  proposal  for  IDAFIPS 
OPFORCES  interface. 

This  completes  the  discussion  of  SNAP  I/SPLICE 
interface.  SNAP  II  interface  will  next  be  addressed. 


D.  BACKGROUND  SNAP  II 

SNAP  II  is  the  small  ship  equivalent  of  SNAP  I.  It  is 
based  on  a  Harris  computer  system  that  is  configured  to  use 
the  same  type  data  files  as  the  SNAP  I  computer  to  promote 
interchangeability  of  data.  The  goal  of  SNAP  II  is  very 
similar  to  that  of  SNAP  I's:  to  provide  the  maximum 
automated  interface  possible  with  other  fleet  and  shore 
based  automated  information  systems  (either  on-line  or  off¬ 
line)  or  activities  and  to  require  minimal  supply, 
maintenance,  and  training  support.  The  SNAP  II  Shipboaru 
Management  Overview  Guide  calls  for  the  system  to:  [Ref. 

HU 

Provide  each  ship  with  a  fully  automated  logistics 
management  system  that  interfaces  with  the  Weapons 
System  File  (WSF)  and  all  other  shore  data  bases. 

SNAP  II,  like  SNAP  I,  replaces  most  of  the  manual 
systems  onboard  the  ships  by  combining  the  information  that 


they  use  into  a  common  data  base.  This  data  base  is  used  to 
produce  internal  reports  and  data,  as  well  as  reports  for 
off  ship  use.  SNAP  II  has  five  major  subsystems:  System 
Management  Subsystem  (SMS),  Maintenance  Data  Subsystem 
(MDS),  Supply  and  Financial  Management  (SFM),  Adm  i  n  i  s t r a t  i  v e 
Data  Management  (ADM),  and  Mobile  Logistics  Support  Force 
(MLS).  A  general  description  of  each  follows: 

1.  SMS  is  concerned  with  the  management  of  the  computer 
and  the  data  base  and  has  little  need  for  outside 
interface  other  than  controlling  the  output  devices 
for  other  functions. 

2.  MDS  provides  the  on-line  interactive  3-M  system  which 
needs  to  communicate  with  the  IMMS  and  CSMP  system  on 
SNAP  I  computers.  The  interface  to  this  system  for 
input  and  output  off  the  ship  is  magnetic  tape. 

3.  SFM  is  an  interactive  system  which  supports  supply 
control,  requisition  processing,  inventory  management, 
COSAL  maintenance,  and  financial  management  functions. 
This  function  needs  to  interface  with  outside  sources 
both  SNAP  I  and  IDA.  The  present  plans  call  for 
magnetic  tape  interfaces. 

4.  ADM  is  to  support  the  sh i p- i n ter nal  Manpower 
management  as  well  as  SDSA  which  has  numerous  off  ship 
interfaces  to  be  maintained. 

5.  MLSF  is  an  automated  data  processing  system  that 
supports  replenishment  functions  on  SAC  224  accounting 
ships. 

At  times,  a  function  may  utilize  more  than  one  subsystem 
when  entering  or  extracting  data. 


E.  SNAP  II  SUPPORT  APPLICATION  INTERFACES 

SNAP  II,  as  implemented,  has  dramatically  reduced  the 
amount  of  manual  effort  required  to  provide  the  information 
and  documentation  that  is  needed  to  perform  the  support 


administration  and  logistic  functions  necessary  onboard 
small  ships.  In  that  the  inputs  and  outputs  of  the  two 
systems  are  similar,  SNAP  II  could  benefit,  in  much  the  same 
ways  as  SNAP  I  was  shown  to  have  benefitted,  from  a 
telecommunications  interface  with  shore  based  sites.  In 
light  of  this,  no  repetition  of  the  required  interface 
initiatives  and  programs  will  be  repeated  here. 

The  major  problem  in  interfacing  SNAP  II  units  with 
SPLICE  is  that  SNAP  II  hardware  will  only  support  an 
async hronous ,  intelligent  terminal/PC  oriented  off-ship 
interface,  instead  of  the  above  interface  and  the 
synchronous  interface  described  in  the  SNAP  I  section.  The 
connection  to  a  SPLICE  host  would  have  to  be  via  dial-up 
phone  line  from  their  Zenith-150  (IBM  Compatible)  PC 
terminals,  when  not  operating  directly  off  the  SNAP  II 
computers,  through  a  terminal  emulation  package  compatible 
with  SPLICE.  This  could  be  accomplished  by  using  a 
software/ha rd ware  product  such  as  MicroGate  6530,  a  TANDEM 
6530  terminal  emulation  package,  that  enables  PCs  full 
access  to  all  the  features  available  of  a  TANDEM,  plus  the 
ability  to  up  or  download  files.  A  good  discussion  of  some 
alternative  ways  to  implement  SPLICE  interconnection  is 
provided  in  [Ref.  115]. 

The  final  area  that  will  be  addressed  is  how  SNAP  II 
tactically  supports  or  can  be  made  to  better  support  the 
proposed  SPLICE  objectives,  thereby  supporting  previously 


presented  corporate  and  project  goals  and  strategies.  SNAP 
II  directly  supports  and/or  is  supported  by  the  following 
SPLICE  project  objectives:  12,  15,  16,  19,  21,  22,  33,  anc 
35  . 


There  are  several  recommendations  the  authors  have  for 
possible  enhancements  to  SPLICE/SNAP  II  that  will  enable 
them  to  provide  greater  support  or  benefit  to  the 
corporation  and  to  the  Navy  as  a  whole: 

1.  Investigate  and  test  the  software  to  support  the  SNAP 
II  user  interfaces  to  the  SPLICE  system  via  the  smart 
terminal/PCs  installed  on  the  ships  and  a  modem  using 
an  asynchronous  interface.  This  interface  would 
provide  for  both  shipboard  on-line  inquiry  and  bulk 
file  transfer  capabilities  using  software  such  as  the 
MicroGate  6530. 

2.  Investigate  the  possibility  for  using  SPLICE  to 
provide  the  gateway  to  ODN  for  shipboard  users  using 
NARDACs  as  hosts.  This  would  provide  shipboard  access 
and  system  interoperability  necessary  for  systems  such 
SDSA  and  IQAFMS. 

3.  Investigate  the  possibility  of  using  SPLICE  for 
shipboard  access  to  AUTODIN  I  via  a  DDA  interface  at 
the  NARDACs,  including  the  SNAP  II  ship  DDN  accounts/ 
electronic  mail  boxes  being  located  there.  This  would 
allow  all  SPLICE  users  and  DDN  users  the  ability  to 
send  information  electronically  to  the  ships.  Data 
such  as  COSAL  updates.  Disbursing,  Financial,  and 
Personnel  documents,  returns,  and  reports  could  then 
be  passed  to  the  shore  community  in  this  manner  on¬ 
line. 

This  concludes  the  discussion  of  SNAP  II.  The  NALCOMIS- 
SPLICE  interface  will  next  be  addressed. 


F.  NRNM  APPLICATION  INTERFACES 

The  Naval  Aviation  Logistics  Command  Management 
Information  System  (NALCOMIS)  interface  to  the  logistics 


222 


community  is  through  the  NALCOMIS  Repairables  Management 
Module  (NRMM).  NRMM  interfaces  with  both  SNAP  I  SUADPS  and 
shore  based  air  stations  via  UAOPS-SP  or  UADPS-LEVEL  11.92 
NRMM  runs  on  the  SNAP  I  computers  as  a  real-time,  managemen 
information  system.  It  was  designed  to  increase  and  prov  id 
better  support  of  the  aviation  logistics  and  maintenance 
efforts  of  squadrons  while  they  are  shore  based  or  embarked 
on  ships. 

NRMM  will  take  both  terminal  inputs  and  magnetic  tape 
inputs.  Its  data  is  stored  on  magnetic  disks  that  can  be 
accessed  by  users  from  remote  terminals  located  on  the 
ships.  Outputs  consist  of  terminal  displays,  printed 
reports,  magnetic  tapes,  disk,  punch  cards,  and  paper  punch 
tape. 

NRMM  is  designed  to  allow  its  users  to  achieve  rapid 
retrieval  of  information  from  its  data  base  or  input  to  it. 
In  doing  so,  it  allows  users  to  monitor  all  facets  of  an 
IMA's  logistic  data:  status  of  outstanding  requisitions, 
local  rotatable  pool  assets,  support  equipment,  and  cross- 
reference  of  part  numbers  and  stock  numbers  for  degree  of 
family  interchangeability.  The  system  also  provides 
technical  publication  records,  tracking  of  cannibalized 
assets  for  each  airframe,  as  well  as  performing  other 
administrative  tasks. 

92in  this  document  the  authors  will  address  only  the 
UAOPS-SP  interface;  insufficient  information  concerning  the 
UAOPS-Level  II  interface  was  available  to  address  it. 


N R M M  interfaces  ashore  to  UADPS-SP,  and  afloat  to 
SUAOPS,  by  using  punch ed  cards  and  magnetic  tapes  as  both 
input  and  output.  The  NRMM  outputs  are  mainly  requisitions 
and  follow-ups  for  material.  Its  external  logistics  inputs 
are  to  NRMM  are  requisition  status  images  and  management 
data  information  via  Master  Stock  Item  Records  (MSIR) 
updates.  Selected  MSIR  data  from  UADPS-SP  is  actually 
overlayed  on  the  NRMM  data  base.  This  is  called  Aviation 
Coordinated  Allowance  List  (AVCAL)  update.  During  this 
process,  the  NRMM  records  are  updated  to  reflect  MSIR 
material  management  information  such  as  on-hand  quantities, 
MCC,  LMC,  COG,  SMIC,  SM&R,  and  purpose  codes.  NRMM  also 
uses  the  results  of  UADPS  processing  of  the  FMSO  change 
notice  action  tapes  to  update  the  NRMM  NSN  records.  [Ref 
116] 

Since  NRMM  will  be  running  shipboard  on  SNAP  I  hardware 
it  seems  that  instead  of  using  magnetic  tapes  or  punched 
cards  as  input  and  output  to  the  Air  Stations  or  Stock 
Points  that  the  same  SNAP  I  telecommunications  interfaces 
recommended  earlier  could  also  benefit  NRMM.  Since  many  Air 
Stations  are  also  SPLICE  sites,  the  updates  from  the 
replicated  MSIR  or  UADPS-SP  status  of  requisitions  could  be 
sent  via  SPLICE  telecommunications  to  the  NRMM/SNAP  I 
hardware  site,  via  the  file  up! oad / d own  1 oad  capabilites 
described  in  the  SNAP  I  section  above,  vice  hand  carried  in 
c  ard / ta  pe  fo  rm  a  t . 
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In  that  NRMM  runs  on  the  SNAP  I  hardware,  tne  same 
SPLICE  objectives  that  apply  for  SNAP  I  also  apply  for  NRMM. 
The  recommendations  that  were  made  for  SNAP  I,  hold  equally 
well.  Further  since  NRMM  is  used  on  SNAP  I  hardware  located 
at  the  Naval  Air  Stations  while  the  squadrons  are  not 
deployed,  the  argument  for  development  of  a  bisynchronous 
link  for  intercommunications  to  the  SPLICE  system  at  the  Air 
Stations  or  the  nearest  SPLICE  site  makes  even  more  sense 
then  the  planned  use  of  magnetic  tape  or  cards  for 
information  transfer. 

This  concludes  the  discussion  of  NRMM,  the  final  area  of 
discussion  in  this  chapter  on  shipboard  telecommunications 
i n  tero  per ab  i  1  i  ty . 
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XI.  SUMMARY  AND  CONCLUSIONS 


A.  SUMMARY 

Until  very  recently,  the  SPLICE  project  has  had  a 
limited  effect  on  the  NAVSUP  and  logistics  operational 
communities.  As  has  been  seen  in  this  document,  since  the 
signing  of  the  SPLICE  contract  in  fiscal  year  (FY)  1984  the 
seeds  to  dramatically  increase  that  effect  in  both  range  and 
depth  hav  e  been  laid. 

The  SPLICE  project  began  dynamically  in  the  late  1970's, 
with  plans  for  rapid  development  and  deployment  of  both 
en v i ro nm en ta 1  and  application  software,  based  upon  PE 
systems.  Its  purpose:  to  resolve  Burroughs  capacity, 
telecommunications,  and  arc h i tec tur al  deficiencies,  while 
stand ard i 2  i  ng  stock  point  minicomputers  and  adding 
interactive  processing  capabilities.  When  limitations  in 
this  plan  forced  NAVSUP  to  competitively  solicit  SPLICE 
hardware  and  system  software,  the  project  all  but 
disappeared  from  notice  for  several  years.  The  capacity 
problems  had  to  be  addressed  with  additional  Burroughs  and 
PE  nardware,  while  SPLICE  targeted  applications  migrated  to 
ADP  systems  where  immediate  capacity  was  forthcoming. 

During  this  time,  however,  SPLICE  planning  was  not 
dormant.  As  requirements  and  needs  changed  within  the  stock 
point  system,  SPLICE  changed  with  them.  Although  this 
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caused  great  fluctuations  in  detailed  environmental  designs, 
SPLICE  plans  were  consistently  based  upon  perceived  and 
anticipated  future  needs  of  the  stock  points.  The  SPLICE 
networking  and  i n t e r o p er ab i 1 i t y  plans  support  this  view. 

Once  the  SPLICE  contract  was  within  NAVSUP's  immediate 
grasp  in  FY  1984,  the  project  again  came  forward  into  the 
lime  light,  with  large  amounts  of  capacity  and  Burroughs 
saturation  relief  potentially  available,  but  without 
applications  to  take  advantage  of  it.  At  this  point, 
applications  were  found  and  implemented  for  immediate 
capacity  payback  (i.e.,  TLOO,  FILE  REPS  for  Inquiry, 
TRANSRECON  Offload,  and  Burroughs  Pr e- pr oc e s so r ) .  In  many 
cases,  the  full  potential  for  these  applications  was 
downplayed  in  order  "to  get  something  out  tnere."  Only  now 
are  limited  efforts  underway  to  exploit  SPLICE  processing 
capabilities. 

SPLICE  planning  has  mostly  been  geared  toward  required 
project  Life  Cycle  Management  approvals.  When  NAVSUP 
changed  direction  and  undertook  a  corporate  planning  view, 
SPLICE  plans  were  found  outdated,  still  geared  toward 
immediate  stock  point  environmental  needs,  and  looking 
toward  isolated  stock  point  implementations  (i.e.,  APADE, 
SPLICE  ABE,  STATLOC,  NAVADS,  FMSO  IDA,  and  UCEPS).  There 
has  been  insufficient  time  for  the  project  to  analyze  how  it 
and  these  efforts  could  be  integrated  to  provide  maximum 


benefit  to  the  corporation  at  large,  w  i  t  n  tne  notable 
exception  of  SPLICENet. 

Tnis  work  has  taken  the  "corporate  view"  in  assessing 
tne  SPLICE  project's  goals,  strategies,  and  objectives  in 
order  to  propose  a  revised  set  of  each  for  consideration  a n c 
possible  adoption  (i.e.,  Chapter  III).  These  revised 
planning  tools  were  then  applied  to: 

1.  existing  and  potential  SPLICE  applications,  botn 
centrally  designed  (i.e.,  Chapter  IV)  and  local 
designed  (i.e.,  Chapter  V); 

2.  and  existing  and  potential  interfaces,  both  shorebased 
(i.e..  Chapters  V  and  VII)  and  shipboard  (i.e.. 

Chapter  VIII). 

As  a  result  of  the  review  of  these  tactical  plans,  numerous 
recommendations  have  been  made  throughout  Chapters  III 
through  VIII  on  potential  ways  to  increase  corporate  support 
and  to  achieve  corporate  objectives  through  changes  in 
specific  SPLICE  or  application  initiatives. 

B.  CONCLUSIONS 

The  SPLICE  project  can  have  a  critical  role  to  play 
within  NAVSUP  and  the  stock  point  community.  The  magnitude 
of  this  role  will  be  determined  by  the  degree  that  the 
project  can  integrate  itself  into  the  framework  of  NAVSUP 
corporate  plans  and  objectives,  while  assuming  a  leadership 
role  in  defining  the  interim  stock  point  information 
architecture. 

Between  SPLICE  and  the  Burroughs  B4900  CPU  replacement 
initiatives,  significant  c  a  p  a  c  >  t  y  has  been  brought  to  the 


doorway  of  the  stock  points;  sufficient  capacity,  in  the 
authors'  opinion,  to  sustain  the  stock  points  through  tne 
aecade.  The  B4900  capacity  can  be  implemented  immediately; 
tne  SPLICE  capacity  only  through  new  download  applications, 
the  integration  of  existing  TANDEM  based  efforts,  and 
implementation  of  new  additional  applications,  as  described 
in  this  document.  It  appears  that  the  SPLICE  capacity  will 
be  largely  unused,  however,  due  to  current  plans  to  forgo 
new  S P L I C T  efforts  in  favor  of  the  transition  of  current 
Burroughs  processing  applications  on  the  soon  to  be  procured 
SPAR  hardware. 

If  the  SPLICE  project,  together  with  the  NAVSUP  and  FMSO 
stock  point  functional  codes,  were  to  boldly  take  the 
initiative  to  implement  applications  on  the  already  known 
and  available  SPLICE  systems,  the  need  to  undertake  SPAR 
transition  would  not  exist.  Rather  than  go  through  the 
labors  of  tr an s i t i o n i ng  UADPS-SP  in  its  current  form  and 
implementing  it  at  a  few  NAVSUP  -ites  during  the  remainder 
of  tnis  decade,  tne  authors  have  concluded  that  B4300  and 
SPLICE  UADPS-SP  application  "modernization"  initiatives 
should  be  undertaken.  Permitting  SPLICE  and  the  B4900s  to 
shoulder  the  burden  of  capacity  through  this  decade  would 
relieve  SPAR  from  rusning  into  an  unknown,  costly,  and 
potentially  risky  transition  of  applications  to  new  hardware 
and  software  that  would  do  little  more  than  they  do  today. 

If  only  a  portion  of  the  SPAR  transition  effort  were 


expended  on  SPLICE  initiatives,  real  processing  improvements 
would  be  provided  to  the  stock  points  in  the  snort  term. 

This  would  also  permit  SPAR  to  concentrate  on  UADPS-SP 
modernization:  the  long  term  need  of  and  goal  for  the  s  toe  k 


points. 
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APPENDIX  A 


NAVSUP  STRATEGIC  INFORMATION  SYSTEM  PLAN  OPPORTUNITIES 

I  INVENTORY  MANAGEMENT 


*  1.  Improve  visibility  of  Navy-owned  assets  to  promote 
greater  logistics  support  effectiveness. 

2.  Enhance  weapons  system  management  capabilities. 

3.  Improve  performance  measures  for  determining  weapons 
systems  support  effectiveness. 

4.  Improve  fleet  support  by  use  of  item  essentiality  codes 
and  more  accurate  shortage  cost  estimates  for  wholesale 
repl en  i  shment. 

5.  Improve  retail  aviation  support  through  use  of  a  new 
AVCAL  model  (RIMAIR) . 

6.  Improve  capability  to  make  procure  versus  repair 
decisions  for  intermediate  and  depot  level  repairaoles. 

7.  Improve  supply  effectiveness  with  capability  to  detect 
and  eliminate  supply  pipeline  constrictions  in  a  real  time 
env  ironment . 

8.  Improve  the  capability  to  determine  m  ul  t  i  -  ec  he  1  on 
stocking  decisions  at  wholesale,  intermediate  and  consumer 
levels,  and  by  weapons  system. 

9.  Satisfy  a  SMPG  requirement  by  providing  a  capability  to 
distinguish  sources  of  demand,  i.e.,  customer  in  terms  of 

U I C ,  service,  country,  etc. 

*  10.  Improve  capability  to  provide  ICP  and  stock  point 
managers  with  sensitivity  and  trade  off  analysis  ("what  if" 
models)  results  for  m  a  te  r  i  a  1  /  f  und  s/ e  f  f  ec  t  i  v  en  e  s  s  questions. 

11.  Improve  operational  readiness  for  new  systems  by 
implementing  the  wholesale  provisioning  model. 

12.  Improve  effectiveness  of  SPCC  load  lists  by  adopting 
and  implementing  the  availability  model. 

*  13.  Satisfy  OSD  requirements  (RIMSTOP)  to  implement  a 
t hr e e- ec h e 1 o n  supply  system. 


14.  Improve  techniques  for  measuring  supply  system 
performance  and  customer  satisfaction. 


II  DATA  MANAGEMENT 

*  15.  Improve  inventory  accuracy,  data  quality  and  control 
through  improved  application  design  c  d  operational 
procedures  at  ICPs  and  Stock  Points. 

*  16.  Improve  the  quality  and  accessibility  of  data  by 
establishing  a  program  to  manage  data  as  a  corporate 
resource. 

17.  Improve  systems  effectiveness  through  the  participation 
in  Navy  wide  functional  data  archi tectural  reviews  to 
standardize  systems,  promote  data  sharing  and  streamline 
information  flow. 

*  18.  Reduce  data  redundancy  and  promote  data  sharing, 
accessibility  and  accuracy  through  the  i ncor po r a t  i  o n  of 
common  data  elements  in  an  integrated  data  base  environment 
that  serves  ICPs,  SPs,  HSCs,  and  other  shore  and  afloat 
customers. 

*  19.  Facilitate  interservice  sharing  and  exchange  of  data 
to  improve  common  logistical  support. 

*  20.  Provide  adequate  policy  for  protection  of  ADP 
resources  through  an  effective  ADP  Security  Program. 

21.  Promote  integrity  and  efficiency  by  providing  internal 
controls  in  application  programs  and  environmental  software. 


Ill  SYSTEM  INTEGRATION 

*  22.  Improve  the  use  of  hardware  and  software  systems 
through  the  definition  of  the  integration  requirements  for 
on-going  and  planned  initiatives  such  as  office  automation, 
telecommunications,  SPLICE,  Stock  Point  Replacement  and  ICP 
Resol icitation. 

*  23.  Promote  competition  in  future  information  system 
resource  acquisitions  by  developing  portable  and  machine 
independent  application  programs. 

*  24.  Improve  local  telecommunications  capabilities  at 
NAVSUP  activities  and  Navy  stock  points  by  installing  local 
area  network  s . 


*  25.  Determine  the  requirements  for  automated  exchange  of 
information  between  and  among  field  activities  and 
headquarters  via  a  command  wide  c omm un ic a t i o n s  network. 

*  26.  Improve  the  use  of  m i c r o- c omp u t er s  and  their  off- 
the-shelf  software,  in  the  management  and  exchange  of 
information,  within  and  among  NAVSUP  components. 


IV  SYSTEM  MODERNIZATION 

*  27.  Improve  reliability,  timeliness  and  quality  of  data 
by  reducing  the  use  of  PCAM  equipment  and  hard  copy  outputs 
in  financial,  procurement  and  supply  systems  through  the  use 
of  computer  output  microform  and  video  display  terminals. 

*  28.  Improve  user  capabilites  and  data  processing 
efficiency  and  reliability  through  the  replacement  of 
obsolete,  worn  out  ADPE. 

*  29.  Improve  mobilization  and  workload  expansion 
capabilities  at  ICPs  and  SPs. 

*  30.  Eliminate  Navy-unique  systems  software  through  the 
use  of  vendor  off-the-shelf  environmental  software. 

*  31.  Reduce  paperwork  and  improve  productivity  and 
administrative  management  by  developing  office  automation 
systems  to  provide  tools  such  as  electronic  mail,  text 
editing,  electronic  files,  electronic  calendars,  and 
graphics  within  NAVSUP  HQ  and  its  field  activities. 

*  32.  Improve  productivity  through  automation  of  manual 
processes. 

33.  Improve  management  and  control  of  conventional 
ammunition  inventories  through  the  redesign  of  CAIMS. 

34.  Improve  information  systems  support  services  at  the 
stock  point  and  ICP  data  processing  installations  by 
upgrading  and  expanding  hardware  configurations  and 
facilities,  including  un  in terr uptabl e  power,  air 
conditioning  and  fire  protection. 

35.  Reduce  the  complexity  and  length  of  the  logistics 
information  systems  acquisition  process. 

36.  To  increase  user  effectiveness  and  productivity  and 
improve  the  use  of  Navy  assets  by  providing  better  systems 
and  streamlined  business  methods. 


*  37.  Provide  for  a  less  complex,  more  flexible  and 
reliable  hardware/ software  environment  through  contractual 
vehicles  which  facilitate  technological  refreshment  and  a 
long-term  single  vendor  relationship. 

*  38.  Improve  long  haul  communication  user  access  to  ICP 
and  stock  point  data  through  the  use  of  the  Defense  Data 
Network. 

*  39.  Improve  management  decision  capability  by  enabling 
managers  to  easily  access  and  manipulate  data  through  use  of 
automated  tools. 

*  40.  Improve  logistics  management  by  providing  easy  access 
to  configuration  and  weapons  support  data. 

V  QUALITY  PERSONNEL 

41.  Improve  productivity  and  effectiveness  by  elevating  the 
information  technology  skill  level  of  information  systems 
development  and  user  personnel  through  formal  training 

pr  og  r  am  s  . 

42.  Improve  personnel  posture  through  the  development  and 
implementation  of  a  personnel  planning  program  which  would 
include  training,  mobility,  work  environment,  retention, 
staffing,  grade  structure,  recruitment,  etc. 

43.  Establish  a  cadre  of  functional  personnel  to  improve 
user  effectiveness  through  increased  emphasis  on  functional 
work  requirements  and  deficiency  statements. 


VI  RESOURCE  MANAGEMENT 

44.  Improve  the  execution  of  04  business  functions  through 
aggressive  implementation  of  NAVSUPNOTE  5400  of  20  Nov  84  ( 
04  Reorganization). 

*  45.  Improve  management  and  control  of  local  unique 
application  programs  as  by-products  of  the  ICP 

Resol  ic itation/UADPS-SP  Repl acement. 

46.  Improve  SUP  04  consolidated  budget  information. 

*  47.  Improve  the  way  basic  business  functions  are 
performed  at  stock  points. 

48.  Improve  the  way  basic  business  functions  are  performed 
at  I  CP  s  . 


49.  Focus  resources  and  improve  effectiveness  of  FMSO 
products  and  performance. 


50.  Improve  effectiveness,  quality,  timeliness  and 
auditability  of  responses  to  external  reviews,  audits  ana 
inquiries  from  activities  such  as  Congress,  GAO,  GSA  and  DOD 
and  Navy  organizations. 

51.  Obtain  timely  GAO  certification  of  financial  accounting 
systems . 

52.  Improve  the  use  of  hardware  and  software  resources  by 
establishing  configuration  management  and  capacity 
management  programs. 

*  53.  Insure  continuous  information  systems  services 
through  improved  contingency  capabilities. 

54.  Improve  the  ability  to  acquire  necessary  resources  in 
the  budget  process  as  a  result  of  better  documented 
requirements  through  the  IRM  program. 

55.  Strengthen  NAVSUP's  IRM  resource  acquisition  and  budget 
process  through  the  application  of  SECNAV  LCM  procedures. 

56.  Establish  a  Problem /Opportunity  Hopper  to  provide  early 
visibility  and  control  of  potential  problems  and  targets  of 
opportun  i  ty  . 

57.  Establish  a  formalized  "Lessons  Learned"  process  to 
minimize  repetition  of  past  mistakes. 

58.  Increase  the  use  of  statistical  techniques  to  measure 
and  improve  operations. 

59.  Institutionalize  the  strategic  and  tactical  planning 
process . 

60.  Fulfill  the  CNO  (OP  945)  IRM  planning  requirements 
through  the  SUP  04  strategic  and  tactical  planning  process. 

61.  More  effectively  respond  to  Command  Goals  and 
Objectives  through  the  SUP  04  strategic  and  tactical 
planning  process. 


VII  TECHNOLOGY  EXPLOITATION 


*  62.  Provide  improved  information  systems  technology 
throughout  NAVSUP. 


APPENDIX  B 


NAVSUP  STRATEGIC  INFORMATION  SYSTEMS  PLAN  ASSUMPTIONS 


I.  INVENTORY  MANAGEMENT 

*  1,  The  ICPs  and  SPs  will  continue  to  provide  weapons 
systems  logistics  support  for  the  Navy. 

*  2.  UAOPS-SP,  UICP,  and  Level  II  will  continue  as  NAVSUP' s 
standard  baseline  supply  and  financial  management  systems. 

*  3.  NAVSUP  will  continue  to  be  a  sponsor  for  uniform 
standard  supply  and  financial  information  systems  for  use  by 
Navy  stock  points  external  to  the  NAVSUP  Command. 

4.  Integration  of  wholesale  material  management  across  DOD 
will  increase  and  Navy  ICPs  will  serve  a  broad  range  of  DOD 
and  foreign  government  customers. 

5.  The  number  of  wholesale  line  items  managed  by  Navy  ICPs 
will  decrease  slightly,  but  emphasis  on  repairables  will 
make  item  management  more  complex. 

6.  SMPG  and  other  DOD  initiatives  will  require  development, 
analysis,  and  review  of  MRD  models  and  procedures  at  an 
increased  level  of  effort  and  complexity. 

*  7.  The  Command  emphasis  on  economic  analysis  and 
operations  analysis  will  continue  at  the  current  levels. 

*  8.  The  measurement  of  readiness  and  its  cost  by  weapons 
system  will  receive  increased  emphasis. 

*  9.  There  will  be  increased  pressure  to  use  multi-echelon 
inventory  mod  els. 

*  10.  There  will  be  increased  pressure  to  achieve  complete 
visibility  of  all  inventory  assets. 


II.  DATA  MANAGEMENT 


*  11.  NAVSUP  will  recognize  information  as  a  corporate 
resource  and  implement  in  Information  Resources  Management 
( I RM )  Program. 


*  12.  The  requirement  to  share  common  data  among  DOD 
components,  other  government  agencies  and  contractors  will 
grow  in  emphasis  and  number  of  applications. 

*  13.  Emphasis  on  ADP  Security  will  increase. 

*  14.  Off-the-shelf  DBMSs  and  automated  data  dictionaries 
will  be  used  in  all  major  systems. 


III.  SYSTEM  INTEGRATION 

*  15.  The  hardware  and  software  technology  of  SPLICE,  ICP 
Resolicitation,  Stock  Point  ADP  Replacement  and  office 
automation  will  be  integrated. 

*  16.  The  Defense  Data  Network  will  be  the  basic  long  haul 
communications  network  of  the  Navy. 

*  17.  NAV SUP  04  will  place  increased  emphasis  on  the 
integration  of  afloat  and  ashore  management  information 
sy stem  s . 


IV.  SYSTEM  MODERNIZATION 

*  18.  Use  of  office  automation  and  PCs  will  expand 
significantly  within  NAVSUP  headquarters  and  the  field 
activ i ties. 

*  19.  The  use  of  off-the-shelf  vendor  environmental 
software  will  minimize  the  need  for  Navy-unique 
environmental  software. 

*  20.  The  single  vendor  concept  will  continue  as  the 
preferred  procurement  strategy  for  total  information  systems 
support . 

*  21.  High  level  programming  languages  will  increase  in  use 
for  ad  hoc  reports,  queries,  and  application  programs. 


V.  QUALITY  PERSONNEL 

*  22.  Additional  training  will  be  required  to  meet  the 
needs  of  the  new  technology. 

*  23.  Information  centers  will  assist  and  train  end  users 
in  the  new  information  systems  tools  and  techniques. 

*  24.  New  technology  will  continue  to  generate  a 
requirement  for  specialized  information  systems  skills. 


*  2  5.  It  will  be  increasingly  difficult  to  recruit  and 
retain  employees  because  of  more  attractive  salaries  and 
benefits  within  the  private  sector. 


VI.  RESOURCE  MANAGEMENT 

*  26.  The  internal  organization  will  be  modified  as 
required  to  meet  changing  requi r ements . 

*  27.  The  SUP  04  Strategic  and  Tactical  Information  Systems 
Plans  will  be  the  blue  prints  for  guiding,  shaping,  and 
directing  SUP  0 4 ' s  near  and  long  term  efforts. 

*  28.  NAVSUP  will  continue  to  staff,  manage,  and  operate 
its  own  information  processing  facilities. 

*  29.  A  network  control  center  for  management  and 
administration  of  NAVSUP's  telecommunications  network  will 
be  established. 

*  30.  NAVCOMPTSSA  will  be  the  CDA  for  payroll,  leave,  and 
IDA-SP  applications. 

*  31.  Laws  and  policies  such  as  the  Paperwork  Reduction 
Act,  the  Brooks  Act,  Warner  Amendment,  the  Commercial 
Activities  Program,  and  FARs  will  continue  to  influence  and 
complicate  information  systems  management. 

*  32.  Emphasis  on  fraud,  waste,  and  abuse  and  the  Federal 
Managers  Financial  Integrity  Act  of  1982  will  continue  and 
oversight  will  intensify. 

*  33 .  Tel ec omm un ications  tariff  rates  will  increase  at 
about  20  percent  per  year  over  the  next  3  years. 

*  34.  Efforts  will  be  made  to  replace  current  workload 
measurement  techniques  with  engineered  standards  and 
stati stical  method  s. 

*  35.  There  will  be  continuing  pressure  to  resource 
information  systems  operations  outside  the  NAVSUP  claimancy. 

*  36.  Business  workload  at  SPs  and  ICPs  will  continue  to 
i ncrease . 

*  37.  Use  of  contractors  to  provide  technical  support  will 
increase. 

*  38.  Decision  support  systems  will  be  increasingly 
automated . 


*  39.  Productivity  increases  will  be  used  to  meet  resource 
short  f  a  1 1 s . 

*  40.  There  will  be  increased  emphasis  on  policies  and 
standards  to  effectively  exploit  technology  and  implement 
IRIi  r equ  i  r  emen  t  s  . 

*  41.  There  will  be  an  increased  demand  for  establishing 
and  maintaining  controls  to  more  effectively  manage  SUP  04 
functions. 


VII.  TECHNOLOGY  EXPLOITATION 

*  42.  The  capabilities  of  office  automation  systems  and  PCs 
will  continue  to  increase  with  correspond  ing  improvements  in 
the  price/performance  ratio. 

*  43.  Use  of  off-the-shelf  application  packages  will  be  the 
standard  practice  for  PCs  and  Office  Automation  Systems. 

*  44.  Computer  pr i c e/ per f o rm anc e  ratio  will  continue  to 
improve. 

*  45.  New  application  development  productivity  tools  will 
reduce  the  time  required  to  develop  information  systems. 


APPENDIX  C 


NAVSUP  STRATEGIC  INFORMATION  SYSTEMS  PLAN  STRATEGIES 


I.  INVENTORY  MANAGEMENT 


1.  NAVSUP  04  will  improve  fleet  readiness  through  inventory 
management  by  weapons  system  and  by  achieving  the  mean 
supply  response  time  to  meet  readiness  goals. 

2.  Wholesale  material  requirements  determ ination  emphasis 
will  be  on  repairables  and  high  essentiality  consumables. 

3.  Navy  will  provision  for  all  echelons  of  support. 

*  4.  Navy  supply  support  will  be  provided  through  consumer, 
intermediate  and  wholesale  echelons,  with  the  long  term 
intention  that  calculation  of  inventory  levels  for  these 
echelons  will  be  integrated  to  the  maximum  degree  feasible. 


II.  DATA  MANAGEMENT 


*  5.  NAVSUP  will  manage  information  as  a  corporate 
resource. 

*  6.  The  Data  Administration  program  will  be  impl emented  in 
NAVSUP  to  promote  coordinated  and  integrated  policies, 
programs,  and  procedures  to  efficiently  and  effectively 
manage  and  control  corporate  data  and  supporting  resources. 

*  7.  Security  procedures  based  on  economic  risk  analyses 
will  be  used  to  protect  information  systems  from  erroneous 
denial  of  services,  or  unauthorized  accidental/ intentional 
destruction,  modification,  or  disclosure. 

*  8.  Information  systems  will  be  designed  to  electronically 
collect,  validate  and  process  data  as  close  to  the  source  as 
po  s  s  i  b  1  e  . 


III.  SYSTEM  INTEGRATION 

*  9.  NAVSUP  04  will  emphasize  the  integration  of  logistics, 
business,  and  administrative  information  systems,  through 
standard  coding  structures  and  common  data  bases. 


*  10.  NAVSUP  04  will  establish  a  comprehensive  long 
distance  and  local  telecommunications  network  that  provides 
all  authorized  users,  ashore  and  afloat,  ready  access  to 
logistics  information  in  NAVSUP  data  bases. 


IV.  SYSTEM  MODERNIZATION 

*  11.  NAVSUP  04  will  improve  the  effectiveness  and 
usefulness  of  its  information  systems  by  purifying  data 
bases,  acquiring  efficient  hardware,  software,  facilities 
and  developing  systems  which  meet  customer  needs. 

12.  Emphasis  will  be  placed  on  functional  requirements  vice 
technical  specifications  for  hardware  and  software 
procurements. 

*  13.  Portable  and  machine  independent  application  programs 
will  be  developed  to  promote  competition  in  future 
information  systems  resource  acquisitions. 

*  14.  Proven,  commercially  available  hardware  and  software 
prod  uc  ts  will  be  used  . 


V.  QUALITY  PERSONNEL 

15.  NAVSUP  04' s  employee  training  and  development  programs 
will  emphasize  improved  job  performance. 

16.  NAVSUP  04  will  pursue  a  comprehensive  employee  quality 
of  life  program  that  enhances  job  satisfaction. 

17.  NAVSUP  04  will  pursue  a  military  and  civilian  manager 
mix  that  achieves  an  effective  balance  between  continuity 
and  innovation  in  key  management  positions. 

18.  SUP  04  will  emphasize  employee  productivity, 

acco un tab i 1 i ty ,  performance  quality  and  related  incentive 
sy stem  s . 


VI.  RESOURCE  MANAGEMENT 

*  19.  All  SUP  04  information  systems  actions  will  be 
initially  justified  by  economic  analyses  and  subsequently 
audited  for  achievement  of  analysis  objectives. 

*  20.  NAVSUP  04  will  optimize  the  use  of  FMS0  resources  for 
major  standard  information  systems  with  emphasis  on  new 
bystems  development. 


*  21.  All  SUP  04  information  systems  actions  will  be 
documented  and  managed  through  the  SUP  04  Strategic  and 
Tactical  Information  Systems  Plan  and  will  support  the 
NAVSUP  Corporate  Plan  and  the  Navy  ISSP. 

*  22.  SUP  04  will  apply  Life  Cycle  Management  procedures  as 
the  standard  methodology  for  all  Information  Systems 
projects. 

*  23.  NAVSUP  04  will  improve  the  effectiveness  of  its 
hardware,  software,  and  facilities  through  the 
implementation  of  a  configuration  and  capacity  management 
pr og  r  am  . 

*  24.  NAVSUP  04  will  manage  and  control  the  cost  of  its 
data  processing  services  through  the  initiation  of  customer 
charge-back  systems. 

25.  NAVSUP  04  will  implement  the  organization  in  accordance 
with  the  design  concept. 


VII.  TECHNOLOGY  EXPLOITATION 

*  26.  NAVSUP  04  will  be  the  advocate  for  state-of-the-art 
technology  in  information  system  initiatives. 

*  27.  Technology  refreshment  will  be  built  into  all  long 
term  acquisition  and  budget  strategies. 


APPENDIX  D 


NAVSUP  STRATEGIC  INFORMATION  SYSTEMS  PLAN  OBJECTIVES 


I  INVENTORY  MANAGEMENT 

( FY/Q ) 
TARGET 

OBJECTIVE  STRATEGY  DATE 


1.  Implement  an  improved  3  86/3 

AVCAL  model  (RIMAIR)  at  ASO. 


2.  Implement  item  essentiality  1,2  86/2 

codes  and  more  accurate  shortage 
cost  estimates  for  ICP  wholesale 
repl eni shment. 


*  3.  Implement  sensitivity  and  1,2  86/2 

trade-off  analysis  ("What  If") 

capabilities  to  answer  material/ 

funds/effectiveness  questions  by 

ICP  item  manager. 


4.  Implement  a  uniform  and  3  ,  2  87  /4 

improved  wholesale  provisioning 
model  at  ICPs. 


*  5.  Complete  the  implementation  4  91/4 

of  the  RIMSTOP  capability  at  Navy 

activities. 


6.  Implement  a  sparing  to  3  ,  2  88/4 

availability  model  with  item 
essentiality  coding  to  develop 
a  shipboard  and  aviation 
provisioning  capability. 


OBJECTIVE 


STRATEGY 


(  FY/Q 

TARGET 

DATE 


*  7.  Identify  the  actions  4 

required  to  accelerate  the 
implementation  of  the  multi-echelon 
requirements  determination  model. 

(SUP  1) 


8.  Implement  a  mul  ti  -  ec  he!  on  4 

requirements  determination  model 
(wholesale,  intermediate,  and 
consumer)  for  ICP  replenishment 
by  weapons  systems.  (SUP  18. d.) 


9.  Define  and  implement  a  system  1 

to  measure  supply  and  operational 
availability  performance  objectives 
by  weapons  system.  (SUP  15) 


10.  Define  those  measurements,  levels  1 
of  application  and  systems  required  to 
determine  the  effectiveness  of  the 
supply  system.  (SUP  23) 


*  11.  Validate  rules  and  integrate  2,4 

models  for  procurement  and  repair 
requirements  determination.  (SUP  17) 


*  12.  Develop  and  implement  procedures  4 
to  minimize  repetitive  buys  of 
nonstandard  and  Navy  managed  items.  (SUP  32) 


13.  Support  the  development  1 

of  uniform  weapons  system  and 

related  essentiality  coding.  (SUP  16) 


II  DATA  MANAGEMENT 


*  14.  Establish  an  operational  5,9,25 

I RM  prog  r  am  .  (SUP  10  7) 


86/4 


95/4 


89/4 


86/2 


91/2 


88/4 


90/4 


86/4 


OBJECTIVE 


STRATEGY 


(FY/Q 

TARGET 

DATE 


*  15.  Establish  operational  Data  6 

Administration  and  Data  Base 
Administration  Programs.  (SUP  108) 


*  16.  Write  NAVSUP's  instruction  7 

on  contingency  planning  i ncor pora t  inn 
OPNAVINST  5239.1 


*  17.  Rewrite  the  ADP  security  7 

instruction,  NAVSUPINST  5510. 6A. 


18.  Develop  ICP  mobilization/  7,11 

con  t  i  ng  ency  plan. 


Ill  SYSTEM  INTEGRATION 


*19.  Define  and  overall  9,6 

information  architecture  that 
supports  the  NAVSUP  business 
functions.  (SUP  110) 


*  20,  Develop  the  data  9,5 

architecture  that  supports  the 
overall  information  architecture. 

(SUP  112) 


*  21.  Based  on  the  NAVSUP  information  9,7,11 
arc  h  i  tec  t  ur  e  ,  develop  and  overall  23,12 

technical  plan,  including  telecom¬ 
munications,  office  automation,  and 
security  c  o  n  s  i  d  er  a  t  i  o  n  s  ,  that  exploits 
the  technology  available  through 
existing  and  planned  procurements  such 
as  SPLICE,  ICP,  and  SPAR.  (SUP  113) 


36/2 

86/3 

86/2 

87/1 

86/3 

87/1 

87/3 


OBJECTIVE 


STRATEGY 


(FY/Q 

TARGET 

DATE 


*  22.  Develop  a  policy  which  allows  9  85/4 

for  interim  but  standard  office 
automation  systems  at  NAVSUP  field 
activities,  exclusive  of  ICPs. 


23.  Install  an  integrated  office  9,8,11  88/2 

automation  system  in  NAVSUP  HQ. 


*  24.  Install  a  standard  office  9,8,11  88/2 

automation  architecture  at  NAVSUP 
field  activities  exclusive  of  ICPs 
and  NSCs. 


25.  Install  a  local  area  network  9,8,11  88/2 

in  NAVSUP  HQ. 


*  26.  Install  a  logistics  10,14  89/4 

telecommunications  network  using 
the  Defense  Data  Network  (ODN) 
as  the  backbone  .  ( SUP  81  ) 


27.  Develop  and  implement  a  network  1  0  87  /1 

administration  strategy. 


*  28.  Develop  a  plan  to  improve  10  83/1 

ship  to  shore  c omm un i c a t i o n  of 
logistics  information. 


29.  Install  ICP  secure  network.  10,14,24  87/2 


*  30.  Complete  installation  of  10  86/4 

SPLICE  initial  hardware  at  7  sites. 


*  31.  Complete  installation  of  11  86/4 

SPLICE  upgrade  configurations  at 
8  sites  to  support  application 
i m  p  1  em  en  ta  t  i  o  n  . 


08JECTI VE 

STRATEGY 

(FY/Q) 

TARGET 

DATE 

*  32.  Complete  transfer  of 
communications  devices  from 

Burroughs  communication  processors 
to  SPLICE  communications  subsystems 
at  NAV  SUP  Stock  Points. 

10,23 

86/4 

*  33.  Complete  design,  development 
and  testing  of  SPLICE  Phase  II 
(MAPS  support),  and  prototype  at 

7  si tes . 

10 

86/4 

*  34.  Replace  OLA  PE  7 / 3 2 s  with 

SPLICE  hardware  at  stock  points. 

11 

87/1 

*  35.  Complete  development  of  TCP/IP 
protocol  for  DDN ,  and  prototype  at 
one  site. 

10 

86/2 

*  36.  Define  and  execute  the 
integration  requirements  for 
on-going  and  planned  initiatives 
such  as  SPLICE,  SPAR,  ICP 
Resolicitation  and  office  automation 
through  formal  working  group. 

(SUP  12  and  102) 

9 

89/1 

IV  SYSTEM  MODERNIZATION 

*  3  7.  Implement  the  DOD  Inter¬ 
changeability  and 

Substitutability  System. 

11,8,9 

19,20 

87/1 

*  38.  Develop  a  proposal  for 
establishing  and  operating  an 
Information  Center  at  NAVSUP  HQ. 

11,8,9 

86/4 

39.  Implement  new  weapons  systems 
download  requ i r ements . 

11,8,9 

19.20 

89/1 

259 


OBJECTIVE 

STRATEGY 

(FY/Q) 

TARGET 

DATE 

40.  Implement  Centralized 

Accounting  and  Billing  (CAB) 
processing  procedures  at  the 

Naval  Avionics  Center  and  the 

Level  II  Naval  Air  Stations. 

11,8,9 

19,20 

86/4 

41.  Implement  MILSCAP  contract, 
abstracting  procedures  at  the  ICPs. 

11,8,9 

19,20 

35/3 

*  42.  Complete  installation  of 
Integrated  Disbursing  and 

Accounting  applications  on 

SPLICE  hardware. 

11,8,9 

19,20 

88/2 

*  43.  Prepare  for  implementation  of 
IDA/ FM S  and  NAVCIPS  on  NAVCOMPT 
provided  ADPE  and  application 
software. 

11,8,9 

19,20 

89/4 

44.  Revise  automated  NSF  procedures 
in  accordance  with  OSD  direction. 

11,8,9 

19,20 

88/4 

45.  Automate  DLR  GFM/GFE  at 
contractor  pi  ants. 

11,8,9 

19,20 

89/4 

46.  Modify  financial  and 
suppl.y  applications  (UADPS  and 

UICP)  to  implement  end  use  funding 
of  Aviation  Consolidated  Allowance 
Lists. 

11,8,9 

19,20 

86/3 

47.  Develop  and  implement 

Coordinated  Shipboard  Allowance 

List  (COSAL)  download  capability. 

11,8,9 

19,20 

85/4 

48.  Install  ICP  hardware. 

11,14,24 

89/2 

260 


OBJECTIVE 

STRATEGY 

(FY/Q) 

TARGET 

DATE 

49.  Complete  ICP  Transition. 

11,20 

87/2 

50.  Install  ICP  Office  Automation 

Sy  s  tern  s . 

11,9,24 

86/4 

51.  Implement  "Lights  Out"  Data 

Center  Plan  at  ICPs. 

11,23,24 

88/3 

52.  Ensure  compatibility  of 
inventory  levels  models  and 
information  systems  design.  (SUP  118) 

11 

89/2 

53.  Make  a  decision  on  the  use 
of  SAGE  as  a  portability  and/or 
c  onv  er  s i o  n  tool  . 

13 

86/1 

*  54.  Develop  a  software  portability 
plan. 

13 

86/4 

55.  Receive  vendor  proposals  for 

SPAR  hardware  and  systems  software. 

11,12,24 

86/1 

*  56.  Complete  development  of  the 

SPAR  tr an  si t io n/conv er s  ion  strategy. 

13,19,20 

86/1 

57.  Award  a  contract  for  SPAR 
hardware  and  system  software. 

11,12 

22,24 

87/2 

58.  Award  a  SPAR  conversion  contract. 

11,12,14 

87/3 

59.  Complete  modernized  UADPS-SP 
software  development  on  the  SPAR 
test  bed. 

11,8,13 

19,20 

21  ,22 

89/3 

60.  Complete  deployment  of 
modernized  UADPS-SP. 


11,20,22  92/2 


OBJECTIVE 

STRATEGY 

(FY/Q) 

TARGET 

DATE 

*  61.  Complete  APAOE  Phase  I 
integrated  system  testing. 

11,8,13 

86/1 

62.  Receive  SDP  III  approval 
for  APAOE. 

11,19 

21  ,22 

86/3 

*  63.  Complete  APAOE  installations. 

11 

88/4 

64.  Complete  ICP  Re sy s t em i za t  i  on . 

11,8,9 

19,20,1 

2,3,4 

89/2 

65.  Install  B 4 9 0 0  s  at  NSC  Norfolk. 

11,14 

85/3 

66.  Install  B4800s  and  B4900s 
at  selected  stock  points. 

11,14 

86/4 

67.  Eliminate  B3500s  from  stock 
points. 

11 

86/4 

*  68.  Complete  replacement  of  stock 
point  obsolete  peripheral  equipment. 

11 

87/4 

*  69.  Eliminate  PCAM  equipment  at 

11 

91/1 

ICPs,  NSCs,  CDAs,  and  other  activities 
that  are  within  NAVSUP  control  and  from 
whom  they  receive  input.  (SUP  34) 


70.  Install  un i n te r r up t ab 1 e  power  11  87/2 

supply  (including  diesel  generators) 
capability  at  the  ICPs  and  NSCs. 


71.  Complete  renovation  of  the  NSC 
data  processing  facilities. 


23 


87/4 


OBJECTIVE 


STRATEGY 


(FY/Q) 

TARGET 

DATE 


rXV.VA'A’V.W  TTr* 


*  72.  Incorporate  decision  support 
systems  in  SPAR  and  ICP 
Resolicitation  that  provide  the 
information  required  for  activity 
management  and  HQ  feedback.  (SUP  114) 


*  73.  Develop  and  execute  the 
methodology  to  eliminate  errors  in 
existing  stock  point  and  ICP  data 
bases  and  insure  the  quality  of  new 
input.  (SUP  106) 


11 


11 


74.  Transi tion  CAIMS. 

75.  Resystemize  CAIMS. 


11,14 

11,12,13 

14,19 


V  QUALITY  PERSONNEL 


!•  76.  Facilitate  SUP  04  modular  16 

furniture  installation  and 
-*  physical  relocation. 

i 

77.  Develop  a  SUP  04  organizational  25 

strategy  paper  and  presentation 
appropriate  for  use  at  all  04 

em  pi  oy  ee  1  ev  el  s  . 

I 

78.  Oevelop  a  position  description  25 

and  create  a  position  for  a  SUP  04 

;  adm  in i strati  ve/management  assistant. 


i 


S 


79.  Develop  an  integrated  SUP  04 
training  plan  which  incorporates, 
consolidates,  and  tracks  current 
and  future  training  initiatives, 
including  those  provided  through 
ICP  Re  sol  ic i ta t  ion ,  SPAR,  and 
SPLICE. 


15,18 


I 

v'\  '  v'- 


89/3 

89/3 

86/2 

88/2 

86/1 

85/4 

85/4 

85/4 


OBJECTIVE 


STRATEGY 


80.  Develop  Individual  Development  15 

Plans  for  each  employee  within 
NAVSUP  04. 


81.  Write  position  descriptions  25 

for  and  initiate  personnel  actions 
for  all  positions  in  the  new 
organization. 


82.  Write  m i s s i o n/ pur po se / g o al s  25 

for  each  SUP  04  branch. 


VI  RESOURCE  MANAGEMENT 


83.  Implement  a  consolidated  19 

budget  focal  point  within  SUP  04. 

84.  Establish  policy  and  procedures  21 

for  implementing  and  maintaining  the 

SUP  04  strategic  and  planning  process. 


85.  Institutionalize  a  formal  19 

planning  process  which  supports 

the  requirements  of  SECNAVINST  5230.9. 


86.  Publish  NAVSUP  L CM  instruction  22 

to  implement  SECNAVINST  52  3  1. IB 


87.  Establish  a  policy  for  executing  20 
and  monitoring  the  self-financing 
program  to  ensure  the  focusing  of  CDA 
resources .  ( SUP  62  ) 


88.  Develop  policy  and  procedures 
for  economic  analyses  and  auditing 
requirements  for  system  development 
efforts.  (SUP  43) 


(FY/Q) 

TARGET 

DATE 

86/1 

85/4 

86/1 

86/2 

85/4 

86/2 

86/1 

85/4 


19 


86/3 


OBJECTIVE 


STRATEGY 


(  FY  / 
TARGET 
DATE 


ft 


89.  Develop  and  publish  21 

procedures  for  documenting 
"lessons  1  earned" . 


*  90.  Establish  a  policy  for  19,22 

management  of  local  unique 
appl ications. 


91.  Determine  the  feasibility  19 

of  using  the  operational  availability 
equation  to  measure  the  level  of 
service  provided  by  Automated 
Information  Systems  (AIS).  (SUP  97) 


*  92.  Develop  and  implement  23 

an  operational  hardware  and 
environmental  software  management 
program. 


*  93.  Develop  and  implement  an 
operational  capacity  management 
prog  ram . 


*  94.  Implement  a  charge-back 
system  to  manage  and/or  recover 
costs  from  users  of  the  ICP  and 
stock  point  data  centers  and 
networks . 


95.  Develop  a  policy  to  transfer  25 

ADPE,  telecommunications, 
environmental  software,  and 
resystemized  application  programs 
from  project  to  functional  manager. 


23 


24,14 


86/1 


86/2 


86/4 


89/2 


89/2 


87/1 


86/2 


OBJECTIVE 


STRATEGY 


(  FY / 
TARGET 
DATE 


VII  TECHNOLOGY  EXPLOITATION 


*  96.  Establish  an  emerging  25 

technology  program.  (SUP  70) 


*  97.  Develop  policy  and  techniques  26,27 
for  the  infusion  of  new  and  emerging 
technology  into  NAVSUP  information 
systems. 


*  98.  Develop  and  maintain  a  technical  26 
reference  1  ibrary  on  state-of-the-art 
technology  for  hardware,  software,  and 
system  integration  techniques. 


86/2 

86/2 

86/3 


ATTACHMENT  E 


CURRENT  SPLICE  STRATEGIES 


SUPPORT  STRATEGIES 

1.  Enable  implementation  of  new  UADPS-SP  projects  without 
saturation  of  the  existing  Stock  Point  system  hardware. 

2.  Provide  the  Stock  Points  with  the  interactive 
capabilities  required  by  new  projects  or  download 
"functionally  transparent"  UADPS-SP  applications. 

3.  Develop  modular  telecommunications  subsystem  independent 
of  the  current  Stock  Point  computer  systems  which  will 
simplify  the  eventual  replacement  of  the  Stock  Point 
computer  systems  at  the  end  of  their  useful  life. 

4.  Provide  bulk  file  transfer  capability  for  support  of 
sites  being  provided  Multiple  Activity  Processing  System 
(MAPS)  UADPS-SP  access  from  another  SPLICE  location. 

5.  Develop  a  SPLICE  network  wherein  a  Stock  Point, 
functioning  as  a  node  in  the  network,  will  exchange 
information  with  other  Navy  Stock  Points,  Navy  Inventory 
Control  Points  or  DLA  Stock  Points  with  the  nodes  of  the 
SPLICE  network  connected  via  DDN  or  via  commercial 
communications  facilities. 


6.  Protect  the  existing  UADPS-SP  programs  from  obsolescence 
until  modernization  by  the  Stock  Point  Replacement  Project; 
permit  background  processing  with  Stock  Point  computers 
together  with  SPLICE  interactive  and  telecommunications 

f unc  ti o  ns  . 

7.  Avoid  disruption  of  Stock  Point  systems'  processing 
during  SPLICE  installation  and  implementation  phases; 
configure,  operate  SPLICE  systems  to  assure  improvement  of 
Stock  Point  processing  and  throughput. 

*  8.  Locate  the  SPLICE  hardware  at  sites  currently 
processing  Stock  Point  systems  in  order  to  assure  system 
integration,  expedite  testing  and  installation  and  establish 
standardized  nodes  within  the  SPLICE  network. 


DESIGN  STRATEGIES 


*  9.  Acquire  stand  a rd  hard  ware  and  software  configurations 
for  modular  implementation  at  Stock  Point  and  remote  sites. 

10.  Establish  a  standardized  telecommunications  network. 

11.  Develop  common  interactive  telecommunications 
interface(s)  among  Stock  Points,  remote  sites,  terminal 
configurations. 

*  12.  Support  stand-alone  processing. 

*  13.  Support  front-end  processing. 

*  14.  Interface  with  various  existing  Stock  Point  hardware 
(for  example.  Burroughs,  P  er  k  i  n- E  1m  er  ,  IBM,  Univac,  Tandem). 

15.  Absorb  maximum  communications  functions  currently 
resident  on  Stock  Point  host  systems  (to  free  host 
capacity) . 

*  16.  Insulate  the  applications  from  terminal  and  device 
unique  characteristics,  storage  media,  interprocess  routing, 
and  network  connectivity. 

*  17.  Use  modular  hardware  and  software  that  will  allow 
expansion  and  consolidation  as  workloads  and  requirements 
change  throughout  the  system's  life. 

18.  Use  off-the-shelf  environmental  (system)  hardware  and 
software  to  support  system  availability  and  data  integrity 
so  that  only  single  and  most  multiple  component  failures 
will  not  limit  access  to  the  system  by  system  users. 

19.  Allow  non-SPLICE  computer  systems  at  sites  to 
communicate  with  each  other  without  routing  messages  through 
the  SPLICE  processors. 

20.  Develop  a  centralized  network. 

21.  Prepare  a  teleprocessing  framework  for  the  Stock  Point 
Replacement  Project. 

22.  Replace  selected  MAPS  RJE  equipment  with  SPLICE 
h  ard  war  e/ so  f  twar  e  ;  expand  current  remote  and  local 
processing  features. 


ECONOMIC  STRATEGIES 


*  23.  Acquire  systems  specifically  engineered,  configured 
to  meet  specific  Stock  Point  telecommunications  requirements 


and  provide  enhanced  interactive  processing  features  not 
available  under  Stock  Point  systems. 

*  24.  Acquire  systems  that  can  absorb  multiple  Stock  Point 
front-end  applications  thus  eliminating  separate  terminal 
systems  for  each  project  implementation  and 

con  sol  id  a t  i  ng/ r ed uc  i  ng  hardware,  hardware  maintenance  and 
personnel  costs. 

25.  Install  and  implement  SPLICE  in  a  phased  manner  to 
assure  installation  success,  provide  adequate  time  for 
testing  in  a  phased  approach,  etc. 

*  26.  Specify  and  acquire  systems  that  can  be  configured  in 
standard  ized  units. 

*  27.  Select  limited  numbers  of  applications  for  initial 
SPLICE  processing. 

*  28.  Locate  the  SPLICE  system  in  the  same  facilities  with 
Stock  Points  computers  to  reduce  site/facil ity  costs, 
operator  requirements,  transmission,  transportation,  and 

1 og i Stic  s  costs. 

*  29.  Configure  SPLICE  to  process  in  association  with  Stock 
Point  systems  thus  sharing  workloads,  reducing  operating 
costs,  etc. 

30.  Reduce  telecommunications  line  costs  by  using  a  single 
communications  line  and  single  work  station  to  access  data 
bases  residing  on  multiple  local  host  computers  as  well  as 
remote  computers. 

*  31.  Acquire  SPLICE  systems  based  on  requirements  to  (a) 
support  current  UADPS-SP  and  (b)  thereafter  to  support  the 
Stock  Point  Replacement  Project. 

32.  Design  SPLICE  as  a  telecommunications  foundation  for 
the  Stock  Point  Replacement  Project  to  permit,  if  required, 
phased  transition  to  the  Replacement  environment. 


APPENDIX  F 


PROPOSED  SPLICE  PROJECT  STRATEGIES 


I.  INVENTORY  MANAGEMENT 


1.  In  that  Navy  supply  support  will  be  provided  through 
consumer,  intermediate  and  wholesale  echelons,  SPLICE  will 
serve  as  an  horizontal  and  verticle  integration  vehicle 
through  system  wide  tel ecommun  ications  capabilities  and 
provide  a  window  to  stock  point  data  and  processes  (where 
security  permits)  to  all  echelons  of  the  NAVSUP  corporation. 
(NSISP  Strategy  4;  SPLICE  Goal  1) 

1 1  .  DATA  MANAGEMENT 


2.  SPLICE  will  support  an  environment  and  monitor  the 
development  of  applications  which  can  provide  data  and  asset 
visibility  so  that  information  ’  s  managed  as  a  NAVSUP 
corporate  resource.  (NSISP  Strategy  5;  SPLICE  Goal  2) 

3.  SPLICE  will  adhere  to  the  NAVSUP  Data  Administration 
program  to  promote  coordinated  and  integrated  policies, 
programs,  and  procedures  to  efficiently  and  effectively 
manage  and  control  corporate  data  and  supporting  resources. 
(NSISP  Strategy  6;  SPLICE  Goal  2) 

4.  SPLICE  will  ensure  that  all  implemented  security 
procedures  are  based  on  economic  risk  analyses  and  will  be 
used  to  protect  info’mation  systems  from  erroneous  denial  of 
services,  or  unauthorized  accidental/ intentional 
destruction,  modification,  or  disclosure.  (NSISP  Strategy 
7;  SPLICE  Goal  3) 

5.  SPLICE  information  systems  will  be  designed  to 

el ec tron  ic a  1 1 y  collect,  validate  and  process  data  as  close 
to  the  source  as  possible.  (NSISP  Strategy  8;  SPLICE  Goal 
4) 

III.  SYSTEM  INTEGRATION 


6.  SPLICE  will  emphasize  the  integration  of  logistics, 
business,  and  administrative  inform  at  ion  systems,  through 
the  use  of  standard  SPLICE  minicomputer  hardware  (including 
MAPS  site  replacement),  standard  coding  structures,  commom 
data  elements,  and  common  data  bases  (where  practical). 
(NSISP  Strategy  9;  SPLICE  Goals  1  and  3) 


7.  SPLICE  will  will  serve  as  the  basis  for  an  economic  and 
comprehensive  long  distance  and  local  telecommunications 
network  using  DON  or  commercial  facilities,  that  provides 
all  authorized  users,  ashore  and  afloat,  ready  access  to 
logistics  information  in  NAVSUP  data  bases  from  single 
terminals  and  provide  bulk  file  transfer  capabilities,  . 
(NSISP  Strategy  10;  SPLICE  Goals  1,  2,  and  3) 

IV.  SYSTEM  MODERNIZATION 

8.  SPLICE  will  improve  its  effectiveness  and  usefulness  by 
protecting  existing  UADPS-SP  programs  from  obsolescense 
until  SPAR,  providing  stock  point  interactive  capabilties, 
permitting  the  download  of  "functionally  transparent"  and 
site  local  stock  point  applications,  purifying  data  bases, 
acquiring  efficient  hardware,  software,  facilities, 
developing  systems  which  meet  customer  needs,  and  providing 
a  telecommunications  and  office  automation  foundation  for 
the  SPAR  project  to  permit,  if  required,  phased  transition 
to  the  Replacement  environment.  (NSISP  Strategy  11;  SPLICE 
Goals  1,  2,  and  3) 

9.  All  SPLICE  resident  functional  area  COBOL  applications 
will  be  portable  and  machine  independent  in  order  to 
promote  competition  in  future  information  systems  resource 
acquisitions  and  in  preparation  for  SPAR.  (NSISP  Strategy 
13;  SPLICE  Goal  3) 

10.  SPLICE  will  use  proven,  commercially  available  hardware 
and  software  products,  where  possible,  implemented  in  a 
phased  manner  to  assure  installation  success  and  provide  for 
adequate  test  time.  (NSISP  Strategy  14;  SPLICE  Goal  5) 

VI.  RESOURCE  MANAGEMENT 

11.  All  SPLICE  env  i  ro nmen t  a  1  and  application  actions  will 
be  initially  justified  by  economic  analyses  and  subsequently 
audited  for  achievement  of  analysis  objectives.  (NSISP 
Strategy  19;  SPLICE  £oal  5) 

12.  SPLICE  will  optimize  the  use  of  its  FMSO  resources  for 
major  standard  information  systems  with  emphasis  on  new 
systems  development.  (NSISP  Strategy  20;  SPLICE  Goal  5) 

13.  SPLICE  project  actions  will  be  documented  and  managed 
through  the  SUP  04  Strategic  and  Tactical  Information 
Systems  Plan  and  will  support  the  NAVSUP  Corporate  Plan  and 
the  Navy  ISSP.  (NSISP  Strategy  21;  SPLICE  Goal  5) 

14.  SPLICE  will  continue  to  apply  Life  Cycle  Management 
procedures  as  the  standard  methodology  for  all  its  programs 


and  ensure  same  for  supported  projects.  (NSISP  Strategy  22; 
SPLICE  Goal  5) 

15.  SPLICE  will  improve  the  effectiveness  of  its  hardware, 
software,  and  facilities  through  participation  in  the  NAVSUP 
configuration  and  capacity  management  program,  with 
particular  emphasis  on  ensuring  that  new  UADPS-SP  projects 
do  not  saturate  existing  stock  point  hardware.  (NSISP 
Strategy  23;  SPLICE  Goal  5) 

16.  SPLICE  will  provide  a  customer  charge-back  system, 
through  which  its  c u s tom er s/ u ser s  can  manage  and  control  the 
cost  of  data  processing  services.  (NSISP  Strategy  24; 

SPLICE  Goal  5) 

VII.  TECHNOLOGY  EXPLOITATION 

17.  SPLICE  will  advocate  and  provide  for  state-of-the-art 
technology  in  its  information  system  initiatives.  (NSISP 
Strategy  26;  SPLICE  Goal  7) 

18.  SPLICE  will  provide  technology  refreshment  throughout 
its  life-cycle  through  periodic  site  upgrades,  government  or 
vendor  recommended  component  substitutions,  and  supporting 
budget  strategies.  (NSISP  Strategy  27;  SPLICE  Goal  7) 


APPENDIX  G 


PROPOSED  SPLICE  PROJECT  OBJECTIVES 


I  INVENTORY  MANAGEMENT 


OBJECTIVE 


SPLICE 

STRATEGY 


1.  Implement  sensitivity  and  1,2,5, 

trade-off  analysis  (“What  If")  8,10,17 

capabilities  to  answer  material/ 
f und s/ e f f ec t i v ene ss  questions  by 
Stock  Point  item  managers  through 

the  use  of  SPLICE  locally  networked 

microcomputers.  (NSISP  Objective  3,72) 


2.  Initiate  the  implementation  1,2 

of  the  RIMSTOP  capabilities  through 
SPLICE  at  Navy  Stock  Point  activities. 
(NSISP  Objective  5) 


3.  Identify  the  actions  1,2 

required  to  accelerate  the 
implementation  of  the  m  ul  t  i  -  ec  he  1  on 
requirements  determination  model 
through  implementation  of  planned 
RIMSTOP  capabilities  on  SPLICE. 

(NSISP  Objective  7) 


4.  Validate  rules  and  integrate  1 

models  for  procurement  and  repair 
requirements  determination  at  Stock 
Points  through  APADE.  (NSISP 
Objective  11) 


(FY/Q) 

TARGET 

DATE 

86/4 


91/4 


86/4 


91/2 


OBJECTIVE 


SPLICE 

STRATEGY 


(FY/Q 

TARGET 

DATE 


5.  Develop  and  implement  procedures  1,2 
to  minimize  repetitive  buys  of 
nonstandard  of  Stock  Point  retail 
managed  items  through  APAOE  and 
provide  greater  asset  visibiliy. 

(NSISP  Objective  12) 


II  DATA  MANAGEMENT 


6.  Participate  in  the  NAVSUP  2,6 

IRM  program.  (NSISP  Objective  14) 


7.  Participate  in  the  NAVSUP  Data  3 

Administration  and  Data  Base 
Administration  Programs.  (NSISP 
Objective  15) 


8.  Provide  SPLICE  input  to  the  4 

NAVSUPINST  on  contingency  planning. 

(NSISP  Objective  16) 


9.  PrcvideSPLICEinputto  4 

the  ADP  security  instruction, 

NAVS'JPINST  5510. 6A  based  upon 
FDC's  Security  Access  System. 

(NSISP  Objective  17) 


III  SYSTEM  INTEGRATION 


10.  Provide  SPLICE  input  to  the  6,3 

NAVSUP  information  architecture 
that  supports  the  NAVSUP  business 
functions.  (NSISP  Objective  19) 


11.  Provide  input  to  the  NAVSUP  6,2 

data  architecture  that  supports 

the  overall  information  architecture. 

(NSISP  Objective  11) 


38/4 

86/4 

86/2 

86/3 

86/2 

86/3 

87/1 


OBJECTIVE 


SPLICE 

STRATEGY 


12.  Based  on  the  NAVSUP  information  6,4,8 
arc h i t ec t ur e  ,  develop  SPLICE  15 

technical  plans,  including  telecom¬ 
munications,  office  automation,  and 
security  considerations,  that  exploit 
the  technology  available  through 
the  SPLICE  procurement.  (NSISP 
Objective  21) 


13.  Develop  a  SPLICE  tactical  plan  6 

which  provides  interim  but  standard 
office  automation  systems  at  NAVSUP 
field  activities,  exclusive  of  ICPs. 
(NSISP  Objective  22) 


14.  Install  a  TANDEM  based  standard  6,5,8 

office  automation  architecture  at 

NAVSUP  field  activities  exclusive  of 

ICPs,  FM SO ,  and  NSCs.  (NSISP  Objective 

24) 


15.  Install  a  SPLICE  based  logistics  7,10 
telecommunications  network  using 
the  Defense  Data  Network  (DON) 
as  the  backbone.  (NSISP  Objective  26) 


16.  Develop  and  implement  a  SPLICE  7 

based  plan  to  improve  ship  to  shore 
communication  of  logistics  information. 
(NSISP  Objective  28) 


17.  Complete  installation  of  7,8 

SPLICE  initial  hardware  at  7  sites. 

(NSISP  Objective  30) 


18.  Complete  installation  of 
SPLICE  upgrade  configurations  at 
8  sites  to  support  application 
implementation.  (NSISP  Objective  31) 


(FY/Q) 

TARGET 

DATE 

87/3 


86/4 


88/2 


89/4 


88/1 


86/4 


7,8 


86/4 


( FY/Q ) 

OBJECTIVE 

SPLICE 

STRATEGY 

TARGET 

DATE 

19.  Complete  transfer  of 
communications  devices  from 

Burroughs  communication  procesors 
to  SPLICE  communications  subsystems 
at  NAVSUP  Stock  Points. 

(NSISP  Objective  32) 

7,15 

86/4 

20.  Complete  design,  development 
and  testing  of  SPLICE  Phase  II 
(MAPS  support),  and  prototype  at 

7  sites.  (NSISP  Objective  33) 

7 

86/4 

21.  Replace  OLA  PE  7 / 3  2  s  with 

SPLICE  hardware  at  stock  points  and 
implement  DDA  project  on  same. 

(NSISP  Objective  34) 

8 

87/1 

22.  Complete  development  of  TCP/IP 
protocol  and  service  protocols  for  DDN 
on  SPLICE,  and  prototype  at  one  site. 
(NSISP  Objective  35) 

7 

86/2 

23.  Provide  for  SPAR,  ICP 

6 

89/1 

Resolicitation,  shipboard, 
logistics  system,  and  office 
automation  integration  requirements 
in  all  planned  SPLICE  initiatives. 

( NSI SP  Obj  ec  t  ive  36) 


IV  SYSTEM  MODERNIZATION 


24.  Participate  in  the  implementation  8,5,6  87/1 

of  the  00D  Interchangeability  and  11,12 

Substitutability  System,  through 
on-line  implementation  of  the  ML-N,  MRIL 
and  MCRL  on  SPLICE.  (NSISP  Objective  37) 


OBJECTIVE 

SPLICE 

STRATEGY 

(FY/Q) 

TARGET 

DATE 

25.  develop  a  proposal  for 
interfacing  to  an  Information 

Center  at  NAVSUP  HQ.  (NSISP 

Obj  ec  t  ive  25  ) 

8,5,6 

86/4 

26.  Complete  installation  of 
Integrated  Disbursing  and 

Accounting  applications  on 

SPLICE  hardware.  (NSISP  Objective  42) 

8,5,6 

11,12 

88/2 

27.  Prepare  for  implementation  of 

IDA/ F M S  and  NAVCIPS  on  NAVCOMPT 
provided  ADPE  and  application 
software,  using  SPLICE 
telecommunications  facilities. 

(NSISP  Objective  43) 

8,5,6 

11,12 

89/4 

28.  Develop  a  TANDEM  based  software  9 

portability  plan.  (NSISP  Objective  54) 

86/4 

29.  Provide  input  to  the  SPAR 
tr an s i t io n/ co nv er s  ion  plan  for 

SPLICE  resident  applications  and 
tel ec ommun ica t  ion s  facilities. 

(NSISP  Obj  ective  56) 

9,11,12 

86/1 

30.  Assist  in  APADE  Phase  I 
integrated  system  testing,  perform 
sizing  studies,  and  provide  hardware 
interface  and  environmental 
so f twar e/ te st i ng  support. 

(NSISP  Objective  61) 

8,5,9 

86/2 

31.  Complete  APADE  installations; 

8 

88/4 

assist  in  APADE  prototype;  tune 
appliction  after  installation. 
(NSISP  Objective  63) 


277 


OBJECTIVE 


SPLICE 

STRATEGY 


(  fy/q 

TARGET 

DATE 


32.  Assist  in  the  replacement  of  8 

stock  point  obsolete  peripheral 
equipment,  by  replacing  with  SPLICE 
equipment  where  possible.  (NSISP 
Ob j  ec  t i v  e  6  3) 


33.  Eliminate  PCAM  equipment  at  8 

NSCs  and  other  activities  that  are 
within  NAVSUP  control  through  SPLICE 
OLTP  facilities  and  from  whom  they 
receive  input  through  providing  SPLICE 
telecommunications  interfaces.  (NSISP 
Objective  69) 


34.  Incorporate  decision  support  8 

systems  (downloads  and  micro  based) 
in  SPLICE  that  provide  the  information 
required  for  activity  management  and  HQ 
feedback.  (NSISP  Objective  72) 


35.  Develop  and  execute  a  8 

methodology  to  eliminate  errors  in 
existing  stock  point  data  bases 
through  increased  use  of  OLTP  and 
insure  the  quality  of  new  input. 

(NSISP  Objective  73) 


VI  RESOURCE  MANAGEMENT 


36.  Enforce  the  policy  for  11,14 

management  of  local  unique 
applications  at  stock  points 
on  SPLICE.  (NSISP  Objective  36) 


37.  Participate  in  the  NAVSUP  15 

operational  hardware  and 
environmental  software  management 
program  through  the  SPLICE 
Configuration  Management  System. 

(NSISP  Objective  92) 


87/4 


91/1 


89/3 


89/3 


86/2 


89/2 


OBJECTIVE 


SPLICE 

STRATEGY 


(FY/Q 

TARGET 

DATE 


38.  Participate  in  the  NAVSUP  15 

operational  capacity  management 
program  through  SPLICE  capacity 
expansion,  system  sizing  and 
resource  management  systems. 

(NSISP  Objective  93) 


39.  Implement  a  SPLICE  charge-back  16,10 
system  to  manage  and/or  recover 
costs  from  users  of  stock  point 
data  centers  and  networks. 

(NSISP  Obj  ective  94) 


VII  TECHNOLOGY  EXPLOITATION 


40.  Provide  SPLICE  inputs  to  17,18 

the  NAVSUP  emerging  technology 
program.  (NSISP  Objective  96) 


41.  Using  the  SPLICE  contract  17,18 

substitution  clause  and  LCN  interface 
capability,  provide  for  the  infusion 
of  new  and  emerging  technology  into 
NAVSUP  information  systems.  (NSISP 
Objective  97 ) 


42.  Provide  SPLICE  related  inputs  17, 

to  the  NAVSUP  technical  reference 
1 ibrary  on  state-of-the-art 
technology  for  hardware,  software,  and 
system  integration  techniques. 

(NSISP  Obj  ective  98) 


89/2 


87/1 


86/2 


86/2 


86/3 


OBJECTIVE 


SPLICE 

STRATEGY 


TARGET 

DATE 


43.  Implement  SPLICE  ABE  at  8  NAVSUP  1,5,6 
stock  points.  (NSISP  Objectives  31,  8,9,11, 

32,  56,  73)  12 


44.  Incorporate  bar  code  technology  2,5,8, 


(i.e.,  readers  and  medium  duty  bar  code  10,17,18 
printing  laser  devices)  into  SPLICE  and 
implement  on  applicable  supported 
applications.  (NSISP  Objectives  68,  69, 

73,  97) 


45.  Support  the  download  or  SPLICE  1,2,5, 

disk  placement  of  additional  6,7,8 

Burroughs  Master  or  tape  files 

(e.g.,  MRIL,  ML-N,  MCRL ,  etc.)  for 

inquiry,  stand  alone  processing  and 

source  data  purposes  (NSISP  Objectives 

21,  56,  68,  69,  73) 


46.  Expedite  the  movement  of  End-of-  1,2,8, 
Day  procesing  to  SPLICE,  using  the  15 

SPLICE  maintained  TRANSRECON. 

(NSISP  Objectives  21,  56,  68,  69,  73) 


47.  Support  and  expedit  the  transition  2,5,6 


of  NAVADS  to  the  SPLICE  Environment.  7,8,15 
(NSISP  Objectives  21,  31,  56,  68,  69, 

73) 

48.  Support  and  expedit  integration  2,5,6 

of  NISTARS  concepts  and  programs  8,9,10 

into  SPLICE.  (NSISP  Objectives  21,  12,15,17 

56,  68,  69,  73,  97) 

49.  Support  and  expedit  the  2,5,6 

elimination  of  card  oriented  inventory  8,9,10 
processes  by  transition  of  inventory  12,15,17 
tool  creation  to  SPLICE  using  OLTP. 

(NSISP  Objectives  21,  56,  68,  69,  73, 
and  97) 


4/87 


3/86 


1/87 


2/87 


4/86 


4/86 


4/86 


OBJECTIVE 


SPLICE 

STRATEGY 


(  FY/Q 

TARGET 

DATE 


50.  Support  the  implementations  and  2,5,6 
enhancements  of  SPLICE  TLOD.  8,9,10 

(NSISP  Objectives  21,  56,  68,  69,  73,  12,15,17 

and  97) 
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